<!--{{{-->
<link rel='alternate' type='application/rss+xml' title='RSS' href='index.xml' />
<!--}}}-->
Background: #fff
Foreground: #000
PrimaryPale: #8cf
PrimaryLight: #18f
PrimaryMid: #04b
PrimaryDark: #014
SecondaryPale: #ffc
SecondaryLight: #fe8
SecondaryMid: #db4
SecondaryDark: #841
TertiaryPale: #eee
TertiaryLight: #ccc
TertiaryMid: #999
TertiaryDark: #666
Error: #f88
/*{{{*/
body {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}

a {color:[[ColorPalette::PrimaryMid]];}
a:hover {background-color:[[ColorPalette::PrimaryMid]]; color:[[ColorPalette::Background]];}
a img {border:0;}

h1,h2,h3,h4,h5,h6 {color:[[ColorPalette::SecondaryDark]]; background:transparent;}
h1 {border-bottom:2px solid [[ColorPalette::TertiaryLight]];}
h2,h3 {border-bottom:1px solid [[ColorPalette::TertiaryLight]];}

.button {color:[[ColorPalette::PrimaryDark]]; border:1px solid [[ColorPalette::Background]];}
.button:hover {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::SecondaryLight]]; border-color:[[ColorPalette::SecondaryMid]];}
.button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::SecondaryDark]];}

.header {background:[[ColorPalette::PrimaryMid]];}
.headerShadow {color:[[ColorPalette::Foreground]];}
.headerShadow a {font-weight:normal; color:[[ColorPalette::Foreground]];}
.headerForeground {color:[[ColorPalette::Background]];}
.headerForeground a {font-weight:normal; color:[[ColorPalette::PrimaryPale]];}

.tabSelected{color:[[ColorPalette::PrimaryDark]];
	background:[[ColorPalette::TertiaryPale]];
	border-left:1px solid [[ColorPalette::TertiaryLight]];
	border-top:1px solid [[ColorPalette::TertiaryLight]];
	border-right:1px solid [[ColorPalette::TertiaryLight]];
}
.tabUnselected {color:[[ColorPalette::Background]]; background:[[ColorPalette::TertiaryMid]];}
.tabContents {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::TertiaryPale]]; border:1px solid [[ColorPalette::TertiaryLight]];}
.tabContents .button {border:0;}

#sidebar {display:none}
#sidebarOptions input {border:1px solid [[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel {background:[[ColorPalette::PrimaryPale]];}
#sidebarOptions .sliderPanel a {border:none;color:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:hover {color:[[ColorPalette::Background]]; background:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:active {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::Background]];}

.wizard {background:[[ColorPalette::PrimaryPale]]; border:1px solid [[ColorPalette::PrimaryMid]];}
.wizard h1 {color:[[ColorPalette::PrimaryDark]]; border:none;}
.wizard h2 {color:[[ColorPalette::Foreground]]; border:none;}
.wizardStep {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];
	border:1px solid [[ColorPalette::PrimaryMid]];}
.wizardStep.wizardStepDone {background:[[ColorPalette::TertiaryLight]];}
.wizardFooter {background:[[ColorPalette::PrimaryPale]];}
.wizardFooter .status {background:[[ColorPalette::PrimaryDark]]; color:[[ColorPalette::Background]];}
.wizard .button {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryLight]]; border: 1px solid;
	border-color:[[ColorPalette::SecondaryPale]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryPale]];}
.wizard .button:hover {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Background]];}
.wizard .button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::Foreground]]; border: 1px solid;
	border-color:[[ColorPalette::PrimaryDark]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryDark]];}

.wizard .notChanged {background:transparent;}
.wizard .changedLocally {background:#80ff80;}
.wizard .changedServer {background:#8080ff;}
.wizard .changedBoth {background:#ff8080;}
.wizard .notFound {background:#ffff80;}
.wizard .putToServer {background:#ff80ff;}
.wizard .gotFromServer {background:#80ffff;}

#messageArea {border:1px solid [[ColorPalette::SecondaryMid]]; background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]];}
#messageArea .button {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::SecondaryPale]]; border:none;}

.popupTiddler {background:[[ColorPalette::TertiaryPale]]; border:2px solid [[ColorPalette::TertiaryMid]];}

.popup {background:[[ColorPalette::TertiaryPale]]; color:[[ColorPalette::TertiaryDark]]; border-left:1px solid [[ColorPalette::TertiaryMid]]; border-top:1px solid [[ColorPalette::TertiaryMid]]; border-right:2px solid [[ColorPalette::TertiaryDark]]; border-bottom:2px solid [[ColorPalette::TertiaryDark]];}
.popup hr {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::PrimaryDark]]; border-bottom:1px;}
.popup li.disabled {color:[[ColorPalette::TertiaryMid]];}
.popup li a, .popup li a:visited {color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:active {background:[[ColorPalette::SecondaryPale]]; color:[[ColorPalette::Foreground]]; border: none;}
.popupHighlight {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
.listBreak div {border-bottom:1px solid [[ColorPalette::TertiaryDark]];}

.tiddler .defaultCommand {font-weight:bold;}

.shadow .title {color:[[ColorPalette::TertiaryDark]];}

.title {color:[[ColorPalette::SecondaryDark]];}
.subtitle {color:[[ColorPalette::TertiaryDark]];}

.toolbar {color:[[ColorPalette::PrimaryMid]];}
.toolbar a {color:[[ColorPalette::TertiaryLight]];}
.selected .toolbar a {color:[[ColorPalette::TertiaryMid]];}
.selected .toolbar a:hover {color:[[ColorPalette::Foreground]];}

.tagging, .tagged {border:1px solid [[ColorPalette::TertiaryPale]]; background-color:[[ColorPalette::TertiaryPale]];}
.selected .tagging, .selected .tagged {background-color:[[ColorPalette::TertiaryLight]]; border:1px solid [[ColorPalette::TertiaryMid]];}
.tagging .listTitle, .tagged .listTitle {color:[[ColorPalette::PrimaryDark]];}
.tagging .button, .tagged .button {border:none;}

.footer {color:[[ColorPalette::TertiaryLight]];}
.selected .footer {color:[[ColorPalette::TertiaryMid]];}

.sparkline {background:[[ColorPalette::PrimaryPale]]; border:0;}
.sparktick {background:[[ColorPalette::PrimaryDark]];}

.error, .errorButton {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Error]];}
.warning {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryPale]];}
.lowlight {background:[[ColorPalette::TertiaryLight]];}

.zoomer {background:none; color:[[ColorPalette::TertiaryMid]]; border:3px solid [[ColorPalette::TertiaryMid]];}

.imageLink, #displayArea .imageLink {background:transparent;}

.annotation {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border:2px solid [[ColorPalette::SecondaryMid]];}

.viewer .listTitle {list-style-type:none; margin-left:-2em;}
.viewer .button {border:1px solid [[ColorPalette::SecondaryMid]];}
.viewer blockquote {border-left:3px solid [[ColorPalette::TertiaryDark]];}

.viewer table, table.twtable {border:2px solid [[ColorPalette::TertiaryDark]];}
.viewer th, .viewer thead td, .twtable th, .twtable thead td {background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::Background]];}
.viewer td, .viewer tr, .twtable td, .twtable tr {border:1px solid [[ColorPalette::TertiaryDark]];}

.viewer pre {border:1px solid [[ColorPalette::SecondaryLight]]; background:[[ColorPalette::SecondaryPale]];}
.viewer code {color:[[ColorPalette::SecondaryDark]];}
.viewer hr {border:0; border-top:dashed 1px [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::TertiaryDark]];}

.highlight, .marked {background:[[ColorPalette::SecondaryLight]];}

.editor input {border:1px solid [[ColorPalette::PrimaryMid]];}
.editor textarea {border:1px solid [[ColorPalette::PrimaryMid]]; width:100%;}
.editorFooter {color:[[ColorPalette::TertiaryMid]];}

#backstageArea {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::TertiaryMid]];}
#backstageArea a {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstageArea a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; }
#backstageArea a.backstageSelTab {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
#backstageButton a {background:none; color:[[ColorPalette::Background]]; border:none;}
#backstageButton a:hover {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstagePanel {background:[[ColorPalette::Background]]; border-color: [[ColorPalette::Background]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]];}
.backstagePanelFooter .button {border:none; color:[[ColorPalette::Background]];}
.backstagePanelFooter .button:hover {color:[[ColorPalette::Foreground]];}
#backstageCloak {background:[[ColorPalette::Foreground]]; opacity:0.6; filter:'alpha(opacity:60)';}
/*}}}*/
/*{{{*/
* html .tiddler {height:1%;}

body {font-size:.75em; font-family:arial,helvetica; margin:0; padding:0;}

h1,h2,h3,h4,h5,h6 {font-weight:bold; text-decoration:none;}
h1,h2,h3 {padding-bottom:1px; margin-top:1.2em;margin-bottom:0.3em;}
h4,h5,h6 {margin-top:1em;}
h1 {font-size:1.35em;}
h2 {font-size:1.25em;}
h3 {font-size:1.1em;}
h4 {font-size:1em;}
h5 {font-size:.9em;}

hr {height:1px;}

a {text-decoration:none;}

dt {font-weight:bold;}

ol {list-style-type:decimal;}
ol ol {list-style-type:lower-alpha;}
ol ol ol {list-style-type:lower-roman;}
ol ol ol ol {list-style-type:decimal;}
ol ol ol ol ol {list-style-type:lower-alpha;}
ol ol ol ol ol ol {list-style-type:lower-roman;}
ol ol ol ol ol ol ol {list-style-type:decimal;}

.txtOptionInput {width:11em;}

#contentWrapper .chkOptionInput {border:0;}

.externalLink {text-decoration:underline;}

.indent {margin-left:3em;}
.outdent {margin-left:3em; text-indent:-3em;}
code.escaped {white-space:nowrap;}

.tiddlyLinkExisting {font-weight:bold;}
.tiddlyLinkNonExisting {font-style:italic;}

/* the 'a' is required for IE, otherwise it renders the whole tiddler in bold */
a.tiddlyLinkNonExisting.shadow {font-weight:bold;}

#mainMenu .tiddlyLinkExisting,
	#mainMenu .tiddlyLinkNonExisting,
	#sidebarTabs .tiddlyLinkNonExisting {font-weight:normal; font-style:normal;}
#sidebarTabs .tiddlyLinkExisting {font-weight:bold; font-style:normal;}

.header {position:relative;}
.header a:hover {background:transparent;}
.headerShadow {position:relative; padding:4.5em 0em 1em 1em; left:-1px; top:-1px;}
.headerForeground {position:absolute; padding:4.5em 0em 1em 1em; left:0px; top:0px;}

.siteTitle {font-size:3em;}
.siteSubtitle {font-size:1.2em;}

#mainMenu {position:absolute; left:0; width:10em; text-align:right; line-height:1.6em; padding:1.5em 0.5em 0.5em 0.5em; font-size:1.1em;}

#sidebar {position:absolute; right:3px; width:16em; font-size:.9em;}
#sidebarOptions {padding-top:0.3em;}
#sidebarOptions a {margin:0em 0.2em; padding:0.2em 0.3em; display:block;}
#sidebarOptions input {margin:0.4em 0.5em;}
#sidebarOptions .sliderPanel {margin-left:1em; padding:0.5em; font-size:.85em;}
#sidebarOptions .sliderPanel a {font-weight:bold; display:inline; padding:0;}
#sidebarOptions .sliderPanel input {margin:0 0 .3em 0;}
#sidebarTabs .tabContents {width:15em; overflow:hidden;}

.wizard {padding:0.1em 1em 0em 2em;}
.wizard h1 {font-size:2em; font-weight:bold; background:none; padding:0em 0em 0em 0em; margin:0.4em 0em 0.2em 0em;}
.wizard h2 {font-size:1.2em; font-weight:bold; background:none; padding:0em 0em 0em 0em; margin:0.4em 0em 0.2em 0em;}
.wizardStep {padding:1em 1em 1em 1em;}
.wizard .button {margin:0.5em 0em 0em 0em; font-size:1.2em;}
.wizardFooter {padding:0.8em 0.4em 0.8em 0em;}
.wizardFooter .status {padding:0em 0.4em 0em 0.4em; margin-left:1em;}
.wizard .button {padding:0.1em 0.2em 0.1em 0.2em;}

#messageArea {position:fixed; top:2em; right:0em; margin:0.5em; padding:0.5em; z-index:2000; _position:absolute;}
.messageToolbar {display:block; text-align:right; padding:0.2em 0.2em 0.2em 0.2em;}
#messageArea a {text-decoration:underline;}

.tiddlerPopupButton {padding:0.2em 0.2em 0.2em 0.2em;}
.popupTiddler {position: absolute; z-index:300; padding:1em 1em 1em 1em; margin:0;}

.popup {position:absolute; z-index:300; font-size:.9em; padding:0; list-style:none; margin:0;}
.popup .popupMessage {padding:0.4em;}
.popup hr {display:block; height:1px; width:auto; padding:0; margin:0.2em 0em;}
.popup li.disabled {padding:0.4em;}
.popup li a {display:block; padding:0.4em; font-weight:normal; cursor:pointer;}
.listBreak {font-size:1px; line-height:1px;}
.listBreak div {margin:2px 0;}

.tabset {padding:1em 0em 0em 0.5em;}
.tab {margin:0em 0em 0em 0.25em; padding:2px;}
.tabContents {padding:0.5em;}
.tabContents ul, .tabContents ol {margin:0; padding:0;}
.txtMainTab .tabContents li {list-style:none;}
.tabContents li.listLink { margin-left:.75em;}

#contentWrapper {display:block;}
#splashScreen {display:none;}

#displayArea {margin:1em 17em 0em 14em;}

.toolbar {text-align:right; font-size:.9em;}

.tiddler {padding:1em 1em 0em 1em;}

.missing .viewer,.missing .title {font-style:italic;}

.title {font-size:1.6em; font-weight:bold;}

.missing .subtitle {display:none;}
.subtitle {font-size:1.1em;}

.tiddler .button {padding:0.2em 0.4em;}

.tagging {margin:0.5em 0.5em 0.5em 0; float:left; display:none;}
.isTag .tagging {display:block;}
.tagged {margin:0.5em; float:right;}
.tagging, .tagged {font-size:0.9em; padding:0.25em;}
.tagging ul, .tagged ul {list-style:none; margin:0.25em; padding:0;}
.tagClear {clear:both;}

.footer {font-size:.9em;}
.footer li {display:inline;}

.annotation {padding:0.5em; margin:0.5em;}

* html .viewer pre {width:99%; padding:0 0 1em 0;}
.viewer {line-height:1.4em; padding-top:0.5em;}
.viewer .button {margin:0em 0.25em; padding:0em 0.25em;}
.viewer blockquote {line-height:1.5em; padding-left:0.8em;margin-left:2.5em;}
.viewer ul, .viewer ol {margin-left:0.5em; padding-left:1.5em;}

.viewer table, table.twtable {border-collapse:collapse; margin:0.8em 1.0em;}
.viewer th, .viewer td, .viewer tr,.viewer caption,.twtable th, .twtable td, .twtable tr,.twtable caption {padding:3px;}
table.listView {font-size:0.85em; margin:0.8em 1.0em;}
table.listView th, table.listView td, table.listView tr {padding:0px 3px 0px 3px;}

.viewer pre {padding:0.5em; margin-left:0.5em; font-size:1.2em; line-height:1.4em; overflow:auto;}
.viewer code {font-size:1.2em; line-height:1.4em;}

.editor {font-size:1.1em;}
.editor input, .editor textarea {display:block; width:100%; font:inherit;}
.editorFooter {padding:0.25em 0em; font-size:.9em;}
.editorFooter .button {padding-top:0px; padding-bottom:0px;}

.fieldsetFix {border:0; padding:0; margin:1px 0px 1px 0px;}

.sparkline {line-height:1em;}
.sparktick {outline:0;}

.zoomer {font-size:1.1em; position:absolute; overflow:hidden;}
.zoomer div {padding:1em;}

* html #backstage {width:99%;}
* html #backstageArea {width:99%;}
#backstageArea {display:none; position:relative; overflow: hidden; z-index:150; padding:0.3em 0.5em 0.3em 0.5em;}
#backstageToolbar {position:relative;}
#backstageArea a {font-weight:bold; margin-left:0.5em; padding:0.3em 0.5em 0.3em 0.5em;}
#backstageButton {display:none; position:absolute; z-index:175; top:0em; right:0em;}
#backstageButton a {padding:0.1em 0.4em 0.1em 0.4em; margin:0.1em 0.1em 0.1em 0.1em;}
#backstage {position:relative; width:100%; z-index:50;}
#backstagePanel {display:none; z-index:100; position:absolute; width:90%; margin:0em 3em 0em 3em; padding:1em 1em 1em 1em;}
.backstagePanelFooter {padding-top:0.2em; float:right;}
.backstagePanelFooter a {padding:0.2em 0.4em 0.2em 0.4em;}
#backstageCloak {display:none; z-index:20; position:absolute; width:100%; height:100px;}

.whenBackstage {display:none;}
.backstageVisible .whenBackstage {display:block;}
/*}}}*/
/***
StyleSheet for use when a translation requires any css style changes.
This StyleSheet can be used directly by languages such as Chinese, Japanese and Korean which need larger font sizes.
***/
/*{{{*/
body {font-size:0.8em;}
#sidebarOptions {font-size:1.05em;}
#sidebarOptions a {font-style:normal;}
#sidebarOptions .sliderPanel {font-size:0.95em;}
.subtitle {font-size:0.8em;}
.viewer table.listView {font-size:0.95em;}
/*}}}*/
/*{{{*/
@media print {
#mainMenu, #sidebar, #messageArea, .toolbar, #backstageButton, #backstageArea {display: none ! important;}
#displayArea {margin: 1em 1em 0em 1em;}
/* Fixes a feature in Firefox 1.5.0.2 where print preview displays the noscript content */
noscript {display:none;}
}
/*}}}*/
<!--{{{-->
<div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
<div class='headerShadow'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
<div class='headerForeground'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
</div>
<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>
<div id='sidebar'>
<div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
<div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
</div>
<div id='displayArea'>
<div id='messageArea'></div>
<div id='tiddlerDisplay'></div>
</div>
<!--}}}-->
<!--{{{-->
<div class='toolbar' macro='toolbar [[ToolbarCommands::ViewToolbar]]'></div>
<div class='title' macro='view title'></div>
<div class='subtitle'><span macro='view modifier link'></span>, <span macro='view modified date'></span> (<span macro='message views.wikified.createdPrompt'></span> <span macro='view created date'></span>)</div>
<div class='tagging' macro='tagging'></div>
<div class='tagged' macro='tags'></div>
<div class='viewer' macro='view text wikified'></div>
<div class='tagClear'></div>
<!--}}}-->
<!--{{{-->
<div class='toolbar' macro='toolbar [[ToolbarCommands::EditToolbar]]'></div>
<div class='title' macro='view title'></div>
<div class='editor' macro='edit title'></div>
<div macro='annotations'></div>
<div class='editor' macro='edit text'></div>
<div class='editor' macro='edit tags'></div><div class='editorFooter'><span macro='message views.editor.tagPrompt'></span><span macro='tagChooser excludeLists'></span></div>
<!--}}}-->
To get started with this blank TiddlyWiki, you'll need to modify the following tiddlers:
* SiteTitle & SiteSubtitle: The title and subtitle of the site, as shown above (after saving, they will also appear in the browser title bar)
* MainMenu: The menu (usually on the left)
* DefaultTiddlers: Contains the names of the tiddlers that you want to appear when the TiddlyWiki is opened
You'll also need to enter your username for signing your edits: <<option txtUserName>>
These InterfaceOptions for customising TiddlyWiki are saved in your browser

Your username for signing your edits. Write it as a WikiWord (eg JoeBloggs)

<<option txtUserName>>
<<option chkSaveBackups>> SaveBackups
<<option chkAutoSave>> AutoSave
<<option chkRegExpSearch>> RegExpSearch
<<option chkCaseSensitiveSearch>> CaseSensitiveSearch
<<option chkAnimate>> EnableAnimations

----
Also see AdvancedOptions
<<importTiddlers>>
[img[http://www.healthmetricsnetwork.info/interoperability/images/capital.jpg]]

!! The Challenge 
Policy makers are faced with the task of providing leadership and national laws about health care information. It is a fast moving and highly technical field and the decisions made will affect millions of people. 

!! The Solution 
Policy makers should gather health system stakeholders together and work towards developing a nationally interoperable health system. An interoperable health system will allow stakeholders to capture, share and report on data (data use) that, through regular monitoring and evaluation reveal whether the goals of a program or intervention are successful (indicators). Important policy issues include patient identification, privacy and confidentiality and the adoption of international standards.

!! Discussion
What is the role of government policy in building a national health infrastructure?
Who are the stakeholders in my country/province/city?
Who else would be interested in reading this document?
by Alvin Marcelo

In 1999 I received a small grant from our research unit. I thought about bringing together the stakeholders in the Philippine Healthcare System, to talk about standards. I don't remember what came into my mind, why I wanted them to come together, but I think many of the discussions in many of the health informatics mailing lists from that time were about interoperability and standards. I read about HL7 even if I didn't understand what HL7 was all about the source code level, I sort of agreed with what it meant at the conceptual level.

I brought together the Philippine Medical Association, which is like AMA, the Philippine Hospital Association, the Philippine Health Insurance Corporation, the Department of Health, edition 1999 and together, we crafted what we call the Standards for Health Information in the Philippines, version 99, or SHIP99. 

I tried to have as wide a base as possible. They were all really just looking at me when I was talking about standards to them. They really couldn't understand why it was needed. Health informatics was very new then, even to myself, who was trying to be the proponent. 

We came up with three recommendations: First, is that we should use a common minimum data set, and that the minimum data set would be the set that that is needed for reimbursement. The lead there was the Philippine Health Insurance Corporation, which is like Medicare in the US. They just listed down what elements were important to them and then we grabbed the CDC data elements for emergency department systems, by David Paula, and we got the way that DEEDS wrote update element, it should be thirty characters string, it should be alpha numeric, the last name is the name that's shared amongst all the siblings and things like that, how to redefine identification details. That was the first component. 

The second component was ICD-10 for diagnosis codes. It is easy because a year before that, the Department of Health came out with a memorandum that it would be the standard coding system. I think they were just implementing a WHO recommendation. 

The third component was HL7. That was where I sort of pushed my own agenda. No one knew what HL7 was all about. I didn't even understand what HL7 was all about, except that conceptually, the idea was correct. The problem was, we all signed off on that document. The problem was right before that was supposed to be published, I had to leave for my Post Doc. in National Library of Medicine. There wasn't much leadership after I left. No one took it on to push it, to get all the participating stakeholders to use ICD-10, use DEEDS, and use HL7, and even have an awareness campaign of what all of these three components mean and how they relate to the larger health informatics community, which was not really all that big at the time. 

I didn't get the necessary traction that it needed. SHIP99 was published in 2001, after my two-year fellowship in NLM when I returned. It was crafted in 1999, but was not published until I came back in 2001. 

So nothing came of that, except ICD-10. Because it was a law, that you cannot get reimbursement if you don't code in ICD-10. People started putting attention on ICD-10 and trying to get training from WHO on ICD-10 because if they didn't code their claims on ICD-10 then they wouldn't get paid. I thought that was a good stick to get the standards adopted. 

Of course, ICD-10, many of the complaints on admissions where it was not descriptive enough clinically to store all of the clinical concepts. So in terms of interoperability, there's actually no problem right now in the Philippines because there's no exchange in data between facilities right now. The most experienced there would be HL7 within the hospitals. 

A hospital would have five laboratory machines and they would like all of these machines to feed data from the machines to the clinical data repository so they would have to understand what HL7 is all about, so they can massage the data streams from the laboratories towards the clinical data repository. 

So that's mostly what interoperability is working at, what level right now. It's mostly an integration of machines. 
[img[http://www.healthmetricsnetwork.info/interoperability/images/application_development.jpg]]

!! Recommended Reading 
[[Interoperability]]
[[ICT Issues]]

!! The Challenge 
An interoperable health system requires software applications to collect, process, transport and report on health data. These applications may be required at the facility, district and or national level. How do we fill this need?

!! The Solution 
Applications may be acquired as ready to use applications, as systems requiring modification or they can be developed from scratch. When developing applications from scratch, effort should be made to avoid building something that already exists and to consider how the application will be supported and maintained. Furthermore, interoperability can be strengthened by releasing newly developed applications with an open source license and encouraging developers to make use of existing open source tools.

Applications written for an interoperable health system must have clearly defined points of contact between other applications that they will be interacting with. This point of contact is called an interface. For instance an application may collect data at the clinic level and pass it through an interface to a distinct district level system which then may pass it off to a different national system. These interfaces define the separate domains and make clear the domain of a specific application. Data standards are then used to communicate between applications.

Determining where to start and how to prioritize application development is a critical step. Setting priorities should be done in collaboration with both software developers and non-technical stakeholders. 

Once these domains are understood and priorities are set, a software development process can guide the developers through their required activities. Software development processes and best practices are often skipped when software is developed by an individual or a team with little training or experience. However, adopting processes and best practices will lead to happier stakeholders and usually better outcomes.

Software development processes include:

* waterfall approach
* agile development and other iterative processes

These processes guide the software development team through the process of gathering requirements, developing software and quality assurance. Most modern software development follows an agile development approach, as waterfall approaches tend to result in software that is unable to adapt to changing requirements which are particularly common for the healthcare context.

Application developers should be encouraged to adhere to the following software development best practices:

* Use source control to track code revisions (git, subversion)
* Maintain a bug database (trac, lighthouse)
* Always fix bugs before writing new code or implementing new features
* Keep an up to date schedule
* Refer to a written specification
* Work in quiet conditions free from distractions
* Use dedicated testers to look for bugs and ensure that the application meets the specification
  
(from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000043.html)

Support and maintenance capabilities will be strengthened by having in country experts who have knowledge of how to modify the application or ideally were the original application developers.

!! Further Information 
[[Maturity Model]]
[[Open Source Software]]
Source control - http://github.com, http://subversion.tigris.org/
Bug database - http://github.com, http://trac.edgewall.org, http://lighthouseapp.com

!! Examples from the Field 
[[Developing a System that People Will Use - Philippines]]
Local Application Development Capacity in Malawi

by Simon Old

We have gone from a phase where we had a lot of disparate systems, and although we were talking about person based systems based around the patient, we were still doing a lot of the designing around the organizations that we had. And I think that is the biggest shift we took from the national approach from 2002 onwards. We tried to look at how you would develop a ubiquitous system which was independent of the organization. 

Since 1992, I have lived through three management and structural organizations in the NHS. Those kept undermining where we were with our IT because we designed around the organizations and the functions rather than trying to stand back and say if we look at designing this around patients and where they move, we can probably develop a system that can be a little more independent from some of that change. There was a major report that influenced that, which sort of gave us a lot of criticisms to deal with at that point. It was saying that small amounts of protected IT funding, it was low priority at the delivery end, there wasn't really a nationally led IT network architecture even though we had a network and a number. There was a need to improve coordination of IT resources and procurement in particular. At the time, although we had a network, we had a low level of secure high bandwidth connectivity for NHS staff. There were some major criticisms at that point which led to the more recent approach. We had a definition phase about the structure and about services. That led to looking at four major things to deliver:

* Broadband Access for all clinicians
* Electronic booking system - allowing primary care, secondary care, and referrals to go into a formal electronic booking process
* National prescription service
* National health record service - in its early days particularly targeted at out of hours. That meant that in our primary care system you often had people coming in at night that didn't have access to their paper records.

We also delivered an NHS email system. This has proved very successful, basically linking everyone in the NHS system to everybody else. That infrastructure stuff started a long time ago, but it has underpinned a lot of success. The NHS mail system has 300,000 registered users on it. It is a secure network, etc. There are instances when clinicians know each other well and email each other directly. 

We are trying through the care records service to have more formal ways of making sure that standard discharge summaries and other things have standard processes so that they can get integrated from one electronic record to another. But in between that the clinicians the can email one another directly.
[img[http://www.healthmetricsnetwork.info/interoperability/images/business_requirements.jpg]]

!! Recommended Reading 

!! The Challenge 
Systems are often selected without a clear understanding of the problems that they are expected to solve (business requirements). When a system's capabilities do not match the requirements it is being tasked for, it will fail. 

!! The Solution 
A critical step during system selection is the mapping of business requirements to application functionality. A transparent and documented approach should be taken and will involve knowledgeable information technology staff as well as management. This can help to avoid decisions being made for marketing, funding, political, or other reasons. Requirements and constraints such as functionality, near and long-term needs, financial and technical resources, sustainability, and analytic needs must be carefully considered. 

Advanced monitoring system requirements can include programmatic and financial reporting with advanced features such as support for multi-dimensional data (disaggregation), target support, project cloning, and full customization. These latter requirements may not be obvious in the early stages of monitoring system definition. 

IT infrastructure considerations include connectivity, open source, proprietary systems, and software development. Interoperability, as discussed elsewhere, supports a mix of solutions as appropriate to local needs and phasing implementation of systems.

!! Discussion
1. Describe IT systems that you have used that did not meet your requirements. Discuss how the mismatch between requirements and the final system might have occurred.
2. Create a stakeholder list and discuss each stakeholder's requirements for the project. How can we make sure that stakeholders don't request requirements that are not relevant/necessary?

!! Further Information 
[[Maturity Model]]
[[Interoperability]]

Health Metrics Network Framework - http://www.who.int/healthmetrics/documents/framework/en/index.html

!! Examples from the Field 
[[Proposals without Stakeholders - Philippines]]
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/capturing_electronic_data.jpg]]

!! Recommended Reading 
[[Data Use]]

!! The Challenge 
Getting data into an electronic format is a difficult task. Even if an appropriate question gets asked during a patient visit, it might not be recorded. Even if is recorded, it will often just be written onto a piece of paper that gets filed into a room from where it will never be seen again.

!! The Solution 
Getting data into an electronic format will make it easier to be used and to be reported on than if it is just written on a piece of paper. There are three different approaches for getting data into an electronic format: first, fast and last.

FIRST: Captures electronic data at the point of care. During the caregiving session, the healthcare worker captures the data directly into some kind of electronic system. Devices that facilitate this process include: traditional computers, touchscreen computers, PDAs and cellphones. FIRST systems can provide the patient and or the healthcare worker with a printout, label or some other token to indicate that their data had been captured. In addition to capturing electronic data , the FIRST approach can also facilitate data use at the point of care. It can also improve data quality by validating data and stopping invalid data from being captured (see Improving Accuracy of Data Collection).

FAST: Data gets captured onto paper, but is quickly transcribed into a computer before the patient's visit is complete. Transcription is usually done by a data entry clerk who sits either in the room with the caregiver or close by. When FIRST is not possible, this is an important approach for patient held records like Smartcard based systems that require the data to be in an electronic format before the patient leaves the clinic.

LAST: Data gets transcribed from paper forms sometime after the patient has left the clinic. This might require moving the paper forms to a data entry site that is not located at the health facility. This is the most common approach to capturing electronic data.

!! Further Information 
[[National, International and Donor Reporting]]
[[Improving Accuracy of Data Collection]]

!! Examples from the Field 
First-Baobab
Fast-Smartcare
Last-Eldoret
by Simon Old (NHS)
Where we have had more difficulty is in the more detailed clinical care record. The summary care record is still in its early days. Masses of issues in terms of consent. Overtime we have moved from a notion of a lot of the NHS around implied consent to explicit consent. Even things like role based access. We did a lot of work around role based access. We got that moving along within a government framework. Although there is still some use of that our consent model has tended to move to something now that doesn't actually require the patient to give consent at the point of each contact - about who can see the next bit of information. That is very cultural, even across Europe we find massive differences in the attitude between citizen and state and their data and confidentiality. Certainly in this country, because of certain failures and concerns there has been ever more resistance to national databases. So our consent model has been to move to explicit consent, but that is very cultural dependent upon societies and how their governments are thought of. 
by Mike McKay

Malawi had the fastest HIV treatment scale up in sub-saharan Africa. With close to 250,000 people on treatment, the health system was burdened with the enormous task of keeping track of all of these patients, and procuring the huge amount of drugs required to keep them on treatment. The paper based system that was used began to struggle as the number of people receiving treatment at a clinic increased beyond about 600 people. It was simply too difficult to store, retrieve and create reports from so many paper records. 
Faced with this challenge, the Ministry of Health formed a task force to design an electronic system that could help manage the HIV patient data and reporting. 

Initially, the MoH had planned on one system. But two providers, Baobab Health and the Taiwan Medical Mission both provided reasonable proposals. After an extended period of indecision, the MoH received some guidance that they didn't have to choose a single system. Instead, by requiring the systems to meet the specifications and use data standards, both systems could be piloted. This is what ended up happening, and both systems continue to be active in Malawi, with most of the high burden HIV clinics using one of the electronic systems. Besides allowing the MoH to partner with two NGOs, other benefits emerged from having two systems. Because each system had different approaches and even different interpretations of the specifications, various solutions were tested and the results shared openly between the system implementers. This led to increased innovation, something that wouldn't have been possible if a single system was selected.
by Mike McKay

When I joined Baobab I was asked to lead the software development team in developing a national system for HIV treatment. We decided early on to follow an open source, web based model, because we thought it fit in well with our requirements and our vision for how the system could be used.

It was certainly an adjustment for everyone. We removed Microsoft Windows from all of the laptops at the office and installed Ubuntu. For many it was painful, especially for the programming team who only knew Microsoft Visual Basic. Now they were faced with an operating system that looked completely different. But together we learned where to find answers to our questions and soon found ourselves to be more than simply users of an operating system but more like participants in a community. 

The community aspect was emphasized even more as we got down to business and started programming. We were learning a new programming language from scratch (ruby on rails) and books can only take you so far. So we started hanging out in the #rails channel in internet relay chat (IRC) and found people more than willing to answer our questions (rarely did they tell us to go and read the #@$#%* manual). As we hung out (it felt very social and informal) in IRC a strange thing happened. We certainly were asking questions, but we also found ourselves answering questions! There were people joining the community that knew less than we did, and we were able to help them. It was a good feeling, but it was more than that. Helping other people learn concepts or programming strategies helped to reinforce them in ourselves. Being part of this community made us better programmers than if we had stayed in the more traditional 'consumer' oriented computer programming posture of learning from books exclusively. In a place like Malawi, where few technical books are available, we had discovered something even better - a community based learning.

Now the software that we developed entirely in Malawi is published as its own open source project. People at other organizations and other countries have taken it and reused it for their own projects and we are building our own community around our own software. Recently we have had people from the United States and Europe contribute to the code base that we are rolling out in clinics all over Malawi. We found that open source software, and the community that it fosters, is a perfect fit for developing relevant, appropriate systems in Malawi.

Check out our open source software here: http://www.github.com/baobab or hang out with us on IRC at #baobab on freenode
[img[http://www.healthmetricsnetwork.info/interoperability/images/constructive_meetings.jpg]]

!! The Challenge 
Meetings, whether face-to-face or virtual, are a primary vehicle for organizing coordinated action.  How meetings are prepared, executed, and followed up on, can make the difference between success or stagnation.  Because meetings are a means to an end, attention to how they are conducted is often overlooked. The result can be a waste of participants' time and the result can be very little action.  This can happen even when there are very experienced and capable people meeting together with the best of intentions.

!! The Solution 
Constructive meetings among stakeholders lead to group consensus and individual action. In order to have meetings where these things happen it is important to keep these goals in mind when planning, running and following up after a meeting. Some steps for having constructive meetings are described below:

1. The meeting organizers identify and engage with meeting participants well in advance of the meeting date.  The initial communications include a formal meeting invitation and logistics information.  A second line of communications are then be established to invite participants into the planning process.  Discussion of issues is opened up, and ideas for what should be addressed at the meeting are raised.  Some prompting is usually required to encourage participation in this planning process.

It is easy to discount the value of pre-meeting preparation - participants are busy, will wait for the meeting to address issues, etc.  However early and wide engagement is critical to fostering a sense of ownership and responsibility for later action and follow through.

As the planning process progresses, discussions and ideas are crystallized into sessions and programmed on an agenda.  This agenda can then be circulated prior to the meeting.

2. Ensure that the right stakeholders with appropriate authority or technical expertise are at the meeting. Often the wrong people are sent to meetings. Communicate the intention to hold a meeting through your networks and wider fora such as mailing lists, if appropriate.  A good planning process will also encourage the right people to attend.

3. During the meeting, a meeting chair or facilitator must pay attention to the meeting dynamics and progress. Individual session leaders may have varying levels of presentation and facilitation expertise. Consensus can happen when everyone has a chance to voice their opinion and when everyone is listening. The facilitator should aim for discussion between stakeholders and try to avoid monologues.  Attention to time will help keep speakers on point.

Consider thinking of the small group format as the "default" session format.  This principle follows from the observation that often, the most interesting and productive time spent at meetings happens in the break times and over lunch.  At these times, we see small groups of individuals having multiple conversations simultaneously.  Bringing the small group format onto the agenda, we find that some degree of redundancy is a small price to pay for moving forward on several fronts at once.  Then, some time for integration of the different groups can bring everyone together and up to speed.  This does not need to be a comprehensive reporting back from each group: not everyone needs to know everything to the same depth as everyone else, in order to be able to act effectively.  Consider other debriefing formats, therefore, other than the report back to plenary.

4. Once consensus is reached, invite individuals to commit to clear, time-bound action items. 

5. Meeting notes must be taken during the meeting and sent out as soon as possible afterwards. Minutes are a great way to keep momentum going and a way to publicly remind all stakeholders about their individual action items.

6. Participants need to be engaged after the meeting, to remind them to follow up on action items and report back to the stakeholders, either as written communication or by including follow up on the agenda for subsequent meetings.

!! Discussion
1. Describe the worst meeting you have ever been to.
2. Describe the best meeting you have ever been to.
3. What motivates you to act?

!! Further Information 
The Secret Sauce of Great Meetings - http://www.thepracticeofleadership.net/2008/03/24/context-purpose-dramas-and-conflict-the-secret-sauce-of-great-meetings/
Meeting Best Practices - http://hwebbjr.typepad.com/openloops/2006/05/meeting_best_pr.html

!! Experiences in the Field
[[An Interoperability Initiative - Philippines]]
{{span{You are currently using an offline version of the website. Visit http://healthmetricsnetwork.info/interoperability/ to contribute.<script>
  if (document.location.protocol!='file:')
      place.style.display='none';
</script>}}} 

This wiki is a collaborative document that needs your contributions to make it more useful. There is an edit link at the top of each section. We encourage you to click on it and begin editing. Authentication is not turned on to encourage easy participation. If this gets abused we will turn it on and make passwords easy to attain.

When editing, please follow the pattern:

The Challenge - what is the problem?
The Solution - what are the approaches to solving it?
Discussion - what questions would be good for people sitting around a table to discuss?
Further Information - links to other sections or external web pages that are relevant
Experiences from the Field - this is where you can tell your story
[img[http://www.healthmetricsnetwork.info/interoperability/images/data_dictionary.jpg]]

!! Recommended Reading 
[[Indicator Selection]]
[[Monitoring and Evaluation]]
[[National, International and Donor Reporting]]

!! The Challenge 
A problem in health information systems is the lack of common precise definitions for data elements.  Definitions may be ambiguous and there may be multiple definitions from different programs that differ in important details.  Data that is collected with imprecise or diverse definitions cannot be aggregated or compared and is a significant barrier to interoperability.  At the individual patient care level, mobile patients may have data generated using different definitions.  This can impact the quality of patient care.

!! The Solution 
Everyone generating and using data should use a shared data dictionary with agreed definitions.  Definitions should be clear, complete and unambiguous.  This will most likely require consensus at the national level involving all stakeholders.  There are existing international vocabularies (see below) for many frequently used health data terms.

The data dictionary contains "metadata" (literally, data about data).  This should be maintained by a central authority with open access.  It should be mandated for all activities to use the standard data dictionary.

A data dictionary will serve as the foundation for a data warehouse which can link data from multiple sources.

!! Further Information 
[[International Standards]]

!!! Vocabularies 
* Logical Observation Identifiers Names and Codes (LOINC) - http://loinc.org
* Systematized Nomenclature of Medicine--Clinical Terms (SNOMED CT) - http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html
* International Classification of Diseases (ICD) - http://www.who.int/classifications/icd/en/

!! Examples from the Field 
[img[http://www.healthmetricsnetwork.info/interoperability/images/data_use.jpg]]

!! Recommended Reading 

!! The Challenge 
Useful data is tediously gathered but often used only for high level reporting. How can data be used more effectively?

!! The Solution 
Using data routinely at all levels increases the value of that data. As data becomes more valued throughout the health system a data driven culture will develop. Not only does this lead to better decision making, but it can also lead to more careful data collection, and ultimately better overall data quality.

For instance, a policy maker will make better procurement decisions if they have data about which drugs are being consumed and at what rate in the field. Or, consider a nurse who has to collect data on side effects from a patient. The next time the nurse sees that patient it would be useful to know that last time they reported side effects, so that the nurse can followup with that patient. Even an aggregate report pinned to the wall at a facility can help staff know what are the most common ailments to be looking for.

Giving the data back to the initial collector at a useful time and in an appropriate format can support decision making thereby helping them do their job better. Data can also be used at points other than the point of collection and the final donor report. Patients, facility managers, districts and other donors can benefit from data as well.

When data is being used by the data collectors it tends to be captured more carefully. This is for the simple reason that the data collector knows that they will be using their own data again - hence they are motivated to make their own job easier by capturing quality data. This positive feedback loop is motivation to put electronic systems at the point of care, as they facilitate not only data collection but the use of data for patient care.

!! Further Information 
[[Use it or Lose it]]
[[Data for Patient Care]]
[[Operations Management]]

!! Examples from the Field 
[img[http://www.healthmetricsnetwork.info/interoperability/images/data_warehouse.jpg]]

!! Recommended Reading 
[[Enterprise Architecture]]
[[Interoperability]]
[[Business Requirements]]

!! The Challenge 
Health care systems collect a large amount of information from disparate sources. Some of this information is from multiple sources relates to the same subject. This information is potentially useful when combined and analysed as it can give a broader view and also a more comprehensive view of health. How can we collect information from multiple sources and view it in aggregate?

!! The Solution 
When the entire suite of interoperability principles are applied, aggregating and analyzing data from multiple sources becomes possible. It is necessary to have a common data dictionary, good indicator selection, and adopted international standards for data. When these are in place, data can be collected in a data warehouse. A data warehouse makes use of metadata that describes each data source so that it can be appropriately combined and analysed. 

The data warehouse also serves as a repository to allow broad access to data across activities for purposes of comparison. 

!! Further Information 
[[Data Use]]
[[Monitoring and Evaluation]]

Data Warehouse on wikipedia - http://en.wikipedia.org/wiki/Data_warehouse

!! Examples from the Field 
[img[http://www.healthmetricsnetwork.info/interoperability/images/data_for_patient_care.jpg]]

!! Recommended Reading 
[[Interoperability]]
[[Patient Identification]]

!! The Challenge 
Data required for patient care is often considered to be completely separate from public health information. Does this make sense? Can we make data for patient care part of the health information ecosystem?

In resource rich environments, sharing of patient data, either within the facility, between facilities, or vertically up and down a national health information system is often a low priority. Patient data is often seen as something that is shared between patient and provider only as part of the patient encounter with a single provider.  

In resource poor settings, there may not be a single provider within the facility dedicated solely to that patient. Furthermore the patient may be geographically mobile yet still require a continuity of care. Often the community or national approach would require aggregated patient data. These aggregated reporting requirements are even greater when donors are involved and have specific reporting requirement for program monitoring and evaluation.

When the reporting system is the primary driver of facility level health information systems, there is very little incentive for timely and accurate data as the reporting requirement is often not sufficient to ensure proper investment in the information system.

The scope of facility based information systems may include in resource poor settings ensuring compliance with established patient treatment guidelines, improving facility workflows, surveillance of health outcomes of patients, continuity of care of mobile populations or chronic conditions, as well as integration with other HIS systems such as laboratory results, pharmacy ordering and management, radiology and diagnostics, as well as a robust admissions and calendaring system to help manage patient flow.  Some facilities may choose one aspect or another as the primary business problem depending on the most pressing needs, but all must eventually be interconnected either through interoperability standards or some form of integration to improve efficiency and quality. 

!! The Solution 
For any of these functions to happen in a timely and accurate way, the basic areas of interoperability from patient identification, to data dictionaries, to international standards for data transmission, to minimum data sets, as well as data quality issues must be addressed.

Using available clinical ontologies and data dictionaries to maintain comparable data, adopting existing international standards for data reuse between systems (eg lab and patient care), between facilities for mobile populations, and the reporting of data to district, national and international level, can provide a basic informatics infrastructure to use patient data effectively throughout a health information system. 

When facility based information systems can provide some benefit to patient management and facility management improving the lives of the patients and the work lives of the health care workers, a stronger incentive is in place for the entry and use of timely and accurate data. The facility systems may be able to share basic practices to make facility systems more effective for local quality improvement in care and facility management.  These approaches could include basic patient summaries for better triage and care, built in alerts and quality checks to improve patient care, and the ability to view patient data, either individual or from a community, to monitor outcomes and view hidden patterns for better response and resource management. 

!! Further Information 
[[Data Use]]
[[International Standards]]
[[Data Dictionary]]

* WHO Patient Monitoring Guidelines for HIV Care and ART - http://www.who.int/hiv/pub/imai/PatientGuide/en/index.html

!! Examples from the Field 
[[An Interoperability Initiative - Philippines]]

Stories can include the dog bite story, patterns of CD4 counts to monitor potential drug resistence, Eldorets story of improving clinical perfomance of clinical team from 30 patients a day to 90 using patient summaries for better triage, Baobabs use of 'fast food technology' to reduce wait time at admissins by hours.  Such improvements are drivers for more interoperable systems which can only function effectively if health informatics standards are in place and commonly implemented up front.
[[Overview]]

by Alvin Marcelo

We coded side by side with the user, more than just the rapid application development, just really having the health workers tell us, "You put this field here, you make this look red, and then the next page should look like this," and things like that. I think for the first pilot health facility, it's really their baby because they were seeing things develop in front of their eyes. 

That really worked. It's still working six years later. It's a Linux based system. We're not troubleshooting anything at all. They just start on the server, they turn on the workstations, and they are still using it. I guess that's a successful story from that perspective. 

The second health center was a near failure. We were thinking the first center succeeded [bad connection] with asking them to configure it, to make comments about it. As a matter of fact, what we learned there was that it actually helps for them to see the application grow along with them, and that it was a hard thing for the second health center because we were just ramming a whole application down their throat. We were telling them, "Hey! We have this electronic health record now, it's working in the first health center. We have six month's use. There's maternal care, there's vaccines, there's child's ICD Plan, etcetera etcetera." We thought we were the heroes bringing them the goods.

The second health center was a near failure. Coming from the success of the first center, we were so confident that the next one would only be too happy to get the whole system in full (and not have to bother with seeing the software develop what with all the bugs). So we essentially skipped asking them to comment on the software and rushed headlong to training them on all the modules that were available inside. Bad move. The reluctance was strong and there was no immediate ownership of the software ("It's the first center's software isn't it? not ours").  So what we learned is that it actually helps for healthworkers to see the application grow along with them (one module at a time), and that the second health center had a lot of difficulty because we were just ramming a whole application down their throat within a short period of time. Things got fixed much later (they're now going to their 6th year of using CHITS) but that was a close call. We attribute its success to the leadership and persistence of the physician in charge.

What salvaged it for us, for the second health center, was the leadership of the doctor in charge of the facility. He had the leadership to just tell the people, "Quitting is not an option, you just have to do it." As a matter of fact, for about a year, they were doing both paper and computer, can you imagine that? 

They didn't get a buy-in of themselves, of the midwives. They didn't have a buy-in that the computer was stable.

On the third health center, even though we had a complete set of modules, we delivered the application to them in metered doses. 

We just gave them the registration, and then two months later we showed them the maternal care, and then nine months later, because that's the time when a mother would give birth, that's the time we introduced the childcare vaccination module. That worked well from then on. In all the other health centers, we would do that kind of an approach.

It's a metered exposure to the modular system. So they get to mask one module first before going to the next one, even if the modules were already made; even if the modules are already inside. So that's the lesson we have in terms of introducing thematics at the ground level. 

Right now what we're doing is we're converting the training program into a certification program so you can be certified in the registration module and then later on you can be certified in the internal care module.

So we're looking at this as a way for the midwives to start collecting their certifications and use this as sort of badges. Like Girl Scouts or Boy Scouts where you have a badge for registration because you are a master at the registration module another badge for maternal care and EPI. 

So we haven't done an evaluation on that yet but we've seen a lot of interest from the participants because they feel like they've achieved something because they have a certificate to show for it. 
!!!Download
This entire website can be downloaded as a single file that you can use even when there is no internet connection. Right click on the following link and save it to your local machine:
[[Downloadable Interoperability Wiki|wiki.html]]

After downloading the file you can double click it and the saved file will open in your browser even when you are offline.

!!!Print
A printable version is available here:
[[Printable Interoperability Wiki |wiki_print.html]]

A pdf version is also available:
 [[Interoperability Wiki PDF | wiki.pdf]] (~5MB)
[img[http://www.healthmetricsnetwork.info/interoperability/images/enterprise_architecture.jpg]]

!! Recommended Reading 

!! The Challenge 
When confronted with the broad task of 'improving interoperability', it is easy to get confused about where to start.  This document contains information about approaches to specific problems or situations but does not provide a process. It is easy to get bogged down and confused about all of the different interrelated parts that form a health information system and in the whole, the problem can seem overwhelming.  Often attempts to fix one part of the system result in unintended consequences that adversely impact other parts of the system. 

!! The Solution 
The Open Group Architecture Framework (TOGAF) Enterprise Architecture (EA) approach provides a well documented comprehensive method to approach information system improvement.  It is a cyclic iterative process to information system strengthening that ensures that the changes are aligned with the core principles and functions of the organization as well as ensuring that they have institutional support and proper design.

EA begins with a preliminary phase where the support of key stakeholders and governance structures are aligned behind the project.  The effort cannot be successful without this key foundation.
Next, the enterprise architecture is articulated.  This defines the scope and vision of the project.

Following that, the business architecture is developed.  The business architecture phase first describes the current baseline business objectives and processes and then a target business architecture.  Business architecture describes the service strategy and the information architecture to support that as well as the business environment.  A gap analysis is done by looking at the differences between the current and target business architectures.

The Information Architecture includes both application and data architectures.  Based on the gap analysis, the information architecture formulates the requirements for applications and data structures to support the organization's activities.  These manage data and present information which is complete, consistent and stable.

Next, the Technology Architecture looks at the changes which need to be made to information, communication and technology (ICT) infrastructure to support the business, data and applications.

Following this, there is first high level and then more detailed implementation planning and execution.  Following implementation, a 'Change Management' process is initiated which evaluates the impact of the changes and looks at the context of the enterprise.  This is an ongoing process which can alert to organization to the need for an additional iteration of the EA process.

!! Discussion
1. What are you working on that could benefit from the Enterprise Architecture process?

[img[http://www.healthmetricsnetwork.info/interoperability/images/enterprise_architecture_sketch.jpg]]

!! Further Information 
[[Policy and Governance]]
[[Constructive Meetings]]
[[Where Do I Start]]
[[Software Selection]]
[[Interoperability]]
Open Group TOGAF resource site - http://www.opengroup.org/togaf/


!! Examples from the Field 
Papua New Guinea HIS strengthening under Sector-Wide Approach (SWAp)
by Alvin Marcelo

You can actually give the department of health a spreadsheet of fixed data, but they don't want that. They ask the midwives to submit to them paper. So I think the problem is, for interoperability to work, at least two parties would reach an agreement that they would exchange the data in this format. And that's not happened yet in the Philippines. 

The nearest in my experience for the past ten years would be that of the Philippine Heath Insurance Corporation, which is the national medical care. I facilitated them in a workshop where I tried to help them convert their paper claims format into an XML schema. 

We had about three sessions and we were able to come up with a XML schema such that if you have a claim, and you're compliant with the schema then you can submit this XML file to PhilHealth and they would be able to parse it to their system. 

That was research and that's done. PhilHealth does this every year whenever I ask them to but it's just research. We haven't implemented this at the policy level. So it's hard to say that there is interoperability in fact because it's not really implemented in the real sense of the word. No claim is being submitted in XML right now. 

But in terms of concept there is actually a conceptual model, a physical model because it's a schema. There have been XML text messages that have been validated through the schema and that they were able to insert into their own databases.

What's lacking now, I think, is leadership from within the Philippine Health Insurance Corporation to say, okay, we can start accepting XML as long it is compliant with the schema. This is a sign of what's lacking right now. 

The nice thing is that we're not coming from zero. It's like in a five step process, we're at step three. So we're just waiting for the right people to do their work and do step four and then we'll reach step five. 

So that's my problem right now. I can only do so much of the technical domain work at this point. Some people have to take courage and say, "Let's do this; this is the future. Even if we don't understand it we just have to do this." 

But right now I think it's fear. It's more a fear, yeah. 
Blah
/***
|''Name:''|ForEachTiddlerPlugin|
|''Version:''|1.0.8 (2007-04-12)|
|''Source:''|http://tiddlywiki.abego-software.de/#ForEachTiddlerPlugin|
|''Author:''|UdoBorkowski (ub [at] abego-software [dot] de)|
|''Licence:''|[[BSD open source license (abego Software)|http://www.abego-software.de/legal/apl-v10.html]]|
|''Copyright:''|&copy; 2005-2007 [[abego Software|http://www.abego-software.de]]|
|''TiddlyWiki:''|1.2.38+, 2.0|
|''Browser:''|Firefox 1.0.4+; Firefox 1.5; InternetExplorer 6.0|
!Description

Create customizable lists, tables etc. for your selections of tiddlers. Specify the tiddlers to include and their order through a powerful language.

''Syntax:'' 
|>|{{{<<}}}''forEachTiddler'' [''in'' //tiddlyWikiPath//] [''where'' //whereCondition//] [''sortBy'' //sortExpression// [''ascending'' //or// ''descending'']] [''script'' //scriptText//] [//action// [//actionParameters//]]{{{>>}}}|
|//tiddlyWikiPath//|The filepath to the TiddlyWiki the macro should work on. When missing the current TiddlyWiki is used.|
|//whereCondition//|(quoted) JavaScript boolean expression. May refer to the build-in variables {{{tiddler}}} and  {{{context}}}.|
|//sortExpression//|(quoted) JavaScript expression returning "comparable" objects (using '{{{<}}}','{{{>}}}','{{{==}}}'. May refer to the build-in variables {{{tiddler}}} and  {{{context}}}.|
|//scriptText//|(quoted) JavaScript text. Typically defines JavaScript functions that are called by the various JavaScript expressions (whereClause, sortClause, action arguments,...)|
|//action//|The action that should be performed on every selected tiddler, in the given order. By default the actions [[addToList|AddToListAction]] and [[write|WriteAction]] are supported. When no action is specified [[addToList|AddToListAction]]  is used.|
|//actionParameters//|(action specific) parameters the action may refer while processing the tiddlers (see action descriptions for details). <<tiddler [[JavaScript in actionParameters]]>>|
|>|~~Syntax formatting: Keywords in ''bold'', optional parts in [...]. 'or' means that exactly one of the two alternatives must exist.~~|

See details see [[ForEachTiddlerMacro]] and [[ForEachTiddlerExamples]].

!Revision history
* v1.0.8 (2007-04-12)
** Adapted to latest TiddlyWiki 2.2 Beta importTiddlyWiki API (introduced with changeset 2004). TiddlyWiki 2.2 Beta builds prior to changeset 2004 are no longer supported (but TiddlyWiki 2.1 and earlier, of cause)
* v1.0.7 (2007-03-28)
** Also support "pre" formatted TiddlyWikis (introduced with TW 2.2) (when using "in" clause to work on external tiddlers)
* v1.0.6 (2006-09-16)
** Context provides "viewerTiddler", i.e. the tiddler used to view the macro. Most times this is equal to the "inTiddler", but when using the "tiddler" macro both may be different.
** Support "begin", "end" and "none" expressions in "write" action
* v1.0.5 (2006-02-05)
** Pass tiddler containing the macro with wikify, context object also holds reference to tiddler containing the macro ("inTiddler"). Thanks to SimonBaird.
** Support Firefox 1.5.0.1
** Internal
*** Make "JSLint" conform
*** "Only install once"
* v1.0.4 (2006-01-06)
** Support TiddlyWiki 2.0
* v1.0.3 (2005-12-22)
** Features: 
*** Write output to a file supports multi-byte environments (Thanks to Bram Chen) 
*** Provide API to access the forEachTiddler functionality directly through JavaScript (see getTiddlers and performMacro)
** Enhancements:
*** Improved error messages on InternetExplorer.
* v1.0.2 (2005-12-10)
** Features: 
*** context object also holds reference to store (TiddlyWiki)
** Fixed Bugs: 
*** ForEachTiddler 1.0.1 has broken support on win32 Opera 8.51 (Thanks to BrunoSabin for reporting)
* v1.0.1 (2005-12-08)
** Features: 
*** Access tiddlers stored in separated TiddlyWikis through the "in" option. I.e. you are no longer limited to only work on the "current TiddlyWiki".
*** Write output to an external file using the "toFile" option of the "write" action. With this option you may write your customized tiddler exports.
*** Use the "script" section to define "helper" JavaScript functions etc. to be used in the various JavaScript expressions (whereClause, sortClause, action arguments,...).
*** Access and store context information for the current forEachTiddler invocation (through the build-in "context" object) .
*** Improved script evaluation (for where/sort clause and write scripts).
* v1.0.0 (2005-11-20)
** initial version

!Code
***/
//{{{

	
//============================================================================
//============================================================================
//		   ForEachTiddlerPlugin
//============================================================================
//============================================================================

// Only install once
if (!version.extensions.ForEachTiddlerPlugin) {

if (!window.abego) window.abego = {};

version.extensions.ForEachTiddlerPlugin = {
	major: 1, minor: 0, revision: 8, 
	date: new Date(2007,3,12), 
	source: "http://tiddlywiki.abego-software.de/#ForEachTiddlerPlugin",
	licence: "[[BSD open source license (abego Software)|http://www.abego-software.de/legal/apl-v10.html]]",
	copyright: "Copyright (c) abego Software GmbH, 2005-2007 (www.abego-software.de)"
};

// For backward compatibility with TW 1.2.x
//
if (!TiddlyWiki.prototype.forEachTiddler) {
	TiddlyWiki.prototype.forEachTiddler = function(callback) {
		for(var t in this.tiddlers) {
			callback.call(this,t,this.tiddlers[t]);
		}
	};
}

//============================================================================
// forEachTiddler Macro
//============================================================================

version.extensions.forEachTiddler = {
	major: 1, minor: 0, revision: 8, date: new Date(2007,3,12), provider: "http://tiddlywiki.abego-software.de"};

// ---------------------------------------------------------------------------
// Configurations and constants 
// ---------------------------------------------------------------------------

config.macros.forEachTiddler = {
	 // Standard Properties
	 label: "forEachTiddler",
	 prompt: "Perform actions on a (sorted) selection of tiddlers",

	 // actions
	 actions: {
		 addToList: {},
		 write: {}
	 }
};

// ---------------------------------------------------------------------------
//  The forEachTiddler Macro Handler 
// ---------------------------------------------------------------------------

config.macros.forEachTiddler.getContainingTiddler = function(e) {
	while(e && !hasClass(e,"tiddler"))
		e = e.parentNode;
	var title = e ? e.getAttribute("tiddler") : null; 
	return title ? store.getTiddler(title) : null;
};

config.macros.forEachTiddler.handler = function(place,macroName,params,wikifier,paramString,tiddler) {
	// config.macros.forEachTiddler.traceMacroCall(place,macroName,params,wikifier,paramString,tiddler);

	if (!tiddler) tiddler = config.macros.forEachTiddler.getContainingTiddler(place);
	// --- Parsing ------------------------------------------

	var i = 0; // index running over the params
	// Parse the "in" clause
	var tiddlyWikiPath = undefined;
	if ((i < params.length) && params[i] == "in") {
		i++;
		if (i >= params.length) {
			this.handleError(place, "TiddlyWiki path expected behind 'in'.");
			return;
		}
		tiddlyWikiPath = this.paramEncode((i < params.length) ? params[i] : "");
		i++;
	}

	// Parse the where clause
	var whereClause ="true";
	if ((i < params.length) && params[i] == "where") {
		i++;
		whereClause = this.paramEncode((i < params.length) ? params[i] : "");
		i++;
	}

	// Parse the sort stuff
	var sortClause = null;
	var sortAscending = true; 
	if ((i < params.length) && params[i] == "sortBy") {
		i++;
		if (i >= params.length) {
			this.handleError(place, "sortClause missing behind 'sortBy'.");
			return;
		}
		sortClause = this.paramEncode(params[i]);
		i++;

		if ((i < params.length) && (params[i] == "ascending" || params[i] == "descending")) {
			 sortAscending = params[i] == "ascending";
			 i++;
		}
	}

	// Parse the script
	var scriptText = null;
	if ((i < params.length) && params[i] == "script") {
		i++;
		scriptText = this.paramEncode((i < params.length) ? params[i] : "");
		i++;
	}

	// Parse the action. 
	// When we are already at the end use the default action
	var actionName = "addToList";
	if (i < params.length) {
	   if (!config.macros.forEachTiddler.actions[params[i]]) {
			this.handleError(place, "Unknown action '"+params[i]+"'.");
			return;
		} else {
			actionName = params[i]; 
			i++;
		}
	} 
	
	// Get the action parameter
	// (the parsing is done inside the individual action implementation.)
	var actionParameter = params.slice(i);


	// --- Processing ------------------------------------------
	try {
		this.performMacro({
				place: place, 
				inTiddler: tiddler,
				whereClause: whereClause, 
				sortClause: sortClause, 
				sortAscending: sortAscending, 
				actionName: actionName, 
				actionParameter: actionParameter, 
				scriptText: scriptText, 
				tiddlyWikiPath: tiddlyWikiPath});

	} catch (e) {
		this.handleError(place, e);
	}
};

// Returns an object with properties "tiddlers" and "context".
// tiddlers holds the (sorted) tiddlers selected by the parameter,
// context the context of the execution of the macro.
//
// The action is not yet performed.
//
// @parameter see performMacro
//
config.macros.forEachTiddler.getTiddlersAndContext = function(parameter) {

	var context = config.macros.forEachTiddler.createContext(parameter.place, parameter.whereClause, parameter.sortClause, parameter.sortAscending, parameter.actionName, parameter.actionParameter, parameter.scriptText, parameter.tiddlyWikiPath, parameter.inTiddler);

	var tiddlyWiki = parameter.tiddlyWikiPath ? this.loadTiddlyWiki(parameter.tiddlyWikiPath) : store;
	context["tiddlyWiki"] = tiddlyWiki;
	
	// Get the tiddlers, as defined by the whereClause
	var tiddlers = this.findTiddlers(parameter.whereClause, context, tiddlyWiki);
	context["tiddlers"] = tiddlers;

	// Sort the tiddlers, when sorting is required.
	if (parameter.sortClause) {
		this.sortTiddlers(tiddlers, parameter.sortClause, parameter.sortAscending, context);
	}

	return {tiddlers: tiddlers, context: context};
};

// Returns the (sorted) tiddlers selected by the parameter.
//
// The action is not yet performed.
//
// @parameter see performMacro
//
config.macros.forEachTiddler.getTiddlers = function(parameter) {
	return this.getTiddlersAndContext(parameter).tiddlers;
};

// Performs the macros with the given parameter.
//
// @param parameter holds the parameter of the macro as separate properties.
//				  The following properties are supported:
//
//						place
//						whereClause
//						sortClause
//						sortAscending
//						actionName
//						actionParameter
//						scriptText
//						tiddlyWikiPath
//
//					All properties are optional. 
//					For most actions the place property must be defined.
//
config.macros.forEachTiddler.performMacro = function(parameter) {
	var tiddlersAndContext = this.getTiddlersAndContext(parameter);

	// Perform the action
	var actionName = parameter.actionName ? parameter.actionName : "addToList";
	var action = config.macros.forEachTiddler.actions[actionName];
	if (!action) {
		this.handleError(parameter.place, "Unknown action '"+actionName+"'.");
		return;
	}

	var actionHandler = action.handler;
	actionHandler(parameter.place, tiddlersAndContext.tiddlers, parameter.actionParameter, tiddlersAndContext.context);
};

// ---------------------------------------------------------------------------
//  The actions 
// ---------------------------------------------------------------------------

// Internal.
//
// --- The addToList Action -----------------------------------------------
//
config.macros.forEachTiddler.actions.addToList.handler = function(place, tiddlers, parameter, context) {
	// Parse the parameter
	var p = 0;

	// Check for extra parameters
	if (parameter.length > p) {
		config.macros.forEachTiddler.createExtraParameterErrorElement(place, "addToList", parameter, p);
		return;
	}

	// Perform the action.
	var list = document.createElement("ul");
	place.appendChild(list);
	for (var i = 0; i < tiddlers.length; i++) {
		var tiddler = tiddlers[i];
		var listItem = document.createElement("li");
		list.appendChild(listItem);
		createTiddlyLink(listItem, tiddler.title, true);
	}
};

abego.parseNamedParameter = function(name, parameter, i) {
	var beginExpression = null;
	if ((i < parameter.length) && parameter[i] == name) {
		i++;
		if (i >= parameter.length) {
			throw "Missing text behind '%0'".format([name]);
		}
		
		return config.macros.forEachTiddler.paramEncode(parameter[i]);
	}
	return null;
}

// Internal.
//
// --- The write Action ---------------------------------------------------
//
config.macros.forEachTiddler.actions.write.handler = function(place, tiddlers, parameter, context) {
	// Parse the parameter
	var p = 0;
	if (p >= parameter.length) {
		this.handleError(place, "Missing expression behind 'write'.");
		return;
	}

	var textExpression = config.macros.forEachTiddler.paramEncode(parameter[p]);
	p++;

	// Parse the "begin" option
	var beginExpression = abego.parseNamedParameter("begin", parameter, p);
	if (beginExpression !== null) 
		p += 2;
	var endExpression = abego.parseNamedParameter("end", parameter, p);
	if (endExpression !== null) 
		p += 2;
	var noneExpression = abego.parseNamedParameter("none", parameter, p);
	if (noneExpression !== null) 
		p += 2;

	// Parse the "toFile" option
	var filename = null;
	var lineSeparator = undefined;
	if ((p < parameter.length) && parameter[p] == "toFile") {
		p++;
		if (p >= parameter.length) {
			this.handleError(place, "Filename expected behind 'toFile' of 'write' action.");
			return;
		}
		
		filename = config.macros.forEachTiddler.getLocalPath(config.macros.forEachTiddler.paramEncode(parameter[p]));
		p++;
		if ((p < parameter.length) && parameter[p] == "withLineSeparator") {
			p++;
			if (p >= parameter.length) {
				this.handleError(place, "Line separator text expected behind 'withLineSeparator' of 'write' action.");
				return;
			}
			lineSeparator = config.macros.forEachTiddler.paramEncode(parameter[p]);
			p++;
		}
	}
	
	// Check for extra parameters
	if (parameter.length > p) {
		config.macros.forEachTiddler.createExtraParameterErrorElement(place, "write", parameter, p);
		return;
	}

	// Perform the action.
	var func = config.macros.forEachTiddler.getEvalTiddlerFunction(textExpression, context);
	var count = tiddlers.length;
	var text = "";
	if (count > 0 && beginExpression)
		text += config.macros.forEachTiddler.getEvalTiddlerFunction(beginExpression, context)(undefined, context, count, undefined);
	
	for (var i = 0; i < count; i++) {
		var tiddler = tiddlers[i];
		text += func(tiddler, context, count, i);
	}
	
	if (count > 0 && endExpression)
		text += config.macros.forEachTiddler.getEvalTiddlerFunction(endExpression, context)(undefined, context, count, undefined);

	if (count == 0 && noneExpression) 
		text += config.macros.forEachTiddler.getEvalTiddlerFunction(noneExpression, context)(undefined, context, count, undefined);
		

	if (filename) {
		if (lineSeparator !== undefined) {
			lineSeparator = lineSeparator.replace(/\\n/mg, "\n").replace(/\\r/mg, "\r");
			text = text.replace(/\n/mg,lineSeparator);
		}
		saveFile(filename, convertUnicodeToUTF8(text));
	} else {
		var wrapper = createTiddlyElement(place, "span");
		wikify(text, wrapper, null/* highlightRegExp */, context.inTiddler);
	}
};


// ---------------------------------------------------------------------------
//  Helpers
// ---------------------------------------------------------------------------

// Internal.
//
config.macros.forEachTiddler.createContext = function(placeParam, whereClauseParam, sortClauseParam, sortAscendingParam, actionNameParam, actionParameterParam, scriptText, tiddlyWikiPathParam, inTiddlerParam) {
	return {
		place : placeParam, 
		whereClause : whereClauseParam, 
		sortClause : sortClauseParam, 
		sortAscending : sortAscendingParam, 
		script : scriptText,
		actionName : actionNameParam, 
		actionParameter : actionParameterParam,
		tiddlyWikiPath : tiddlyWikiPathParam,
		inTiddler : inTiddlerParam, // the tiddler containing the <<forEachTiddler ...>> macro call.
		viewerTiddler : config.macros.forEachTiddler.getContainingTiddler(placeParam) // the tiddler showing the forEachTiddler result
	};
};

// Internal.
//
// Returns a TiddlyWiki with the tiddlers loaded from the TiddlyWiki of 
// the given path.
//
config.macros.forEachTiddler.loadTiddlyWiki = function(path, idPrefix) {
	if (!idPrefix) {
		idPrefix = "store";
	}
	var lenPrefix = idPrefix.length;
	
	// Read the content of the given file
	var content = loadFile(this.getLocalPath(path));
	if(content === null) {
		throw "TiddlyWiki '"+path+"' not found.";
	}
	
	var tiddlyWiki = new TiddlyWiki();

	// Starting with TW 2.2 there is a helper function to import the tiddlers
	if (tiddlyWiki.importTiddlyWiki) {
		if (!tiddlyWiki.importTiddlyWiki(content))
			throw "File '"+path+"' is not a TiddlyWiki.";
		tiddlyWiki.dirty = false;
		return tiddlyWiki;
	}
	
	// The legacy code, for TW < 2.2
	
	// Locate the storeArea div's
	var posOpeningDiv = content.indexOf(startSaveArea);
	var posClosingDiv = content.lastIndexOf(endSaveArea);
	if((posOpeningDiv == -1) || (posClosingDiv == -1)) {
		throw "File '"+path+"' is not a TiddlyWiki.";
	}
	var storageText = content.substr(posOpeningDiv + startSaveArea.length, posClosingDiv);
	
	// Create a "div" element that contains the storage text
	var myStorageDiv = document.createElement("div");
	myStorageDiv.innerHTML = storageText;
	myStorageDiv.normalize();
	
	// Create all tiddlers in a new TiddlyWiki
	// (following code is modified copy of TiddlyWiki.prototype.loadFromDiv)
	var store = myStorageDiv.childNodes;
	for(var t = 0; t < store.length; t++) {
		var e = store[t];
		var title = null;
		if(e.getAttribute)
			title = e.getAttribute("tiddler");
		if(!title && e.id && e.id.substr(0,lenPrefix) == idPrefix)
			title = e.id.substr(lenPrefix);
		if(title && title !== "") {
			var tiddler = tiddlyWiki.createTiddler(title);
			tiddler.loadFromDiv(e,title);
		}
	}
	tiddlyWiki.dirty = false;

	return tiddlyWiki;
};


	
// Internal.
//
// Returns a function that has a function body returning the given javaScriptExpression.
// The function has the parameters:
// 
//	 (tiddler, context, count, index)
//
config.macros.forEachTiddler.getEvalTiddlerFunction = function (javaScriptExpression, context) {
	var script = context["script"];
	var functionText = "var theFunction = function(tiddler, context, count, index) { return "+javaScriptExpression+"}";
	var fullText = (script ? script+";" : "")+functionText+";theFunction;";
	return eval(fullText);
};

// Internal.
//
config.macros.forEachTiddler.findTiddlers = function(whereClause, context, tiddlyWiki) {
	var result = [];
	var func = config.macros.forEachTiddler.getEvalTiddlerFunction(whereClause, context);
	tiddlyWiki.forEachTiddler(function(title,tiddler) {
		if (func(tiddler, context, undefined, undefined)) {
			result.push(tiddler);
		}
	});
	return result;
};

// Internal.
//
config.macros.forEachTiddler.createExtraParameterErrorElement = function(place, actionName, parameter, firstUnusedIndex) {
	var message = "Extra parameter behind '"+actionName+"':";
	for (var i = firstUnusedIndex; i < parameter.length; i++) {
		message += " "+parameter[i];
	}
	this.handleError(place, message);
};

// Internal.
//
config.macros.forEachTiddler.sortAscending = function(tiddlerA, tiddlerB) {
	var result = 
		(tiddlerA.forEachTiddlerSortValue == tiddlerB.forEachTiddlerSortValue) 
			? 0
			: (tiddlerA.forEachTiddlerSortValue < tiddlerB.forEachTiddlerSortValue)
			   ? -1 
			   : +1; 
	return result;
};

// Internal.
//
config.macros.forEachTiddler.sortDescending = function(tiddlerA, tiddlerB) {
	var result = 
		(tiddlerA.forEachTiddlerSortValue == tiddlerB.forEachTiddlerSortValue) 
			? 0
			: (tiddlerA.forEachTiddlerSortValue < tiddlerB.forEachTiddlerSortValue)
			   ? +1 
			   : -1; 
	return result;
};

// Internal.
//
config.macros.forEachTiddler.sortTiddlers = function(tiddlers, sortClause, ascending, context) {
	// To avoid evaluating the sortClause whenever two items are compared 
	// we pre-calculate the sortValue for every item in the array and store it in a 
	// temporary property ("forEachTiddlerSortValue") of the tiddlers.
	var func = config.macros.forEachTiddler.getEvalTiddlerFunction(sortClause, context);
	var count = tiddlers.length;
	var i;
	for (i = 0; i < count; i++) {
		var tiddler = tiddlers[i];
		tiddler.forEachTiddlerSortValue = func(tiddler,context, undefined, undefined);
	}

	// Do the sorting
	tiddlers.sort(ascending ? this.sortAscending : this.sortDescending);

	// Delete the temporary property that holds the sortValue.	
	for (i = 0; i < tiddlers.length; i++) {
		delete tiddlers[i].forEachTiddlerSortValue;
	}
};


// Internal.
//
config.macros.forEachTiddler.trace = function(message) {
	displayMessage(message);
};

// Internal.
//
config.macros.forEachTiddler.traceMacroCall = function(place,macroName,params) {
	var message ="<<"+macroName;
	for (var i = 0; i < params.length; i++) {
		message += " "+params[i];
	}
	message += ">>";
	displayMessage(message);
};


// Internal.
//
// Creates an element that holds an error message
// 
config.macros.forEachTiddler.createErrorElement = function(place, exception) {
	var message = (exception.description) ? exception.description : exception.toString();
	return createTiddlyElement(place,"span",null,"forEachTiddlerError","<<forEachTiddler ...>>: "+message);
};

// Internal.
//
// @param place [may be null]
//
config.macros.forEachTiddler.handleError = function(place, exception) {
	if (place) {
		this.createErrorElement(place, exception);
	} else {
		throw exception;
	}
};

// Internal.
//
// Encodes the given string.
//
// Replaces 
//	 "$))" to ">>"
//	 "$)" to ">"
//
config.macros.forEachTiddler.paramEncode = function(s) {
	var reGTGT = new RegExp("\\$\\)\\)","mg");
	var reGT = new RegExp("\\$\\)","mg");
	return s.replace(reGTGT, ">>").replace(reGT, ">");
};

// Internal.
//
// Returns the given original path (that is a file path, starting with "file:")
// as a path to a local file, in the systems native file format.
//
// Location information in the originalPath (i.e. the "#" and stuff following)
// is stripped.
// 
config.macros.forEachTiddler.getLocalPath = function(originalPath) {
	// Remove any location part of the URL
	var hashPos = originalPath.indexOf("#");
	if(hashPos != -1)
		originalPath = originalPath.substr(0,hashPos);
	// Convert to a native file format assuming
	// "file:///x:/path/path/path..." - pc local file --> "x:\path\path\path..."
	// "file://///server/share/path/path/path..." - FireFox pc network file --> "\\server\share\path\path\path..."
	// "file:///path/path/path..." - mac/unix local file --> "/path/path/path..."
	// "file://server/share/path/path/path..." - pc network file --> "\\server\share\path\path\path..."
	var localPath;
	if(originalPath.charAt(9) == ":") // pc local file
		localPath = unescape(originalPath.substr(8)).replace(new RegExp("/","g"),"\\");
	else if(originalPath.indexOf("file://///") === 0) // FireFox pc network file
		localPath = "\\\\" + unescape(originalPath.substr(10)).replace(new RegExp("/","g"),"\\");
	else if(originalPath.indexOf("file:///") === 0) // mac/unix local file
		localPath = unescape(originalPath.substr(7));
	else if(originalPath.indexOf("file:/") === 0) // mac/unix local file
		localPath = unescape(originalPath.substr(5));
	else // pc network file
		localPath = "\\\\" + unescape(originalPath.substr(7)).replace(new RegExp("/","g"),"\\");	
	return localPath;
};

// ---------------------------------------------------------------------------
// Stylesheet Extensions (may be overridden by local StyleSheet)
// ---------------------------------------------------------------------------
//
setStylesheet(
	".forEachTiddlerError{color: #ffffff;background-color: #880000;}",
	"forEachTiddler");

//============================================================================
// End of forEachTiddler Macro
//============================================================================


//============================================================================
// String.startsWith Function
//============================================================================
//
// Returns true if the string starts with the given prefix, false otherwise.
//
version.extensions["String.startsWith"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
String.prototype.startsWith = function(prefix) {
	var n =  prefix.length;
	return (this.length >= n) && (this.slice(0, n) == prefix);
};



//============================================================================
// String.endsWith Function
//============================================================================
//
// Returns true if the string ends with the given suffix, false otherwise.
//
version.extensions["String.endsWith"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
String.prototype.endsWith = function(suffix) {
	var n = suffix.length;
	return (this.length >= n) && (this.right(n) == suffix);
};


//============================================================================
// String.contains Function
//============================================================================
//
// Returns true when the string contains the given substring, false otherwise.
//
version.extensions["String.contains"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
String.prototype.contains = function(substring) {
	return this.indexOf(substring) >= 0;
};

//============================================================================
// Array.indexOf Function
//============================================================================
//
// Returns the index of the first occurance of the given item in the array or 
// -1 when no such item exists.
//
// @param item [may be null]
//
version.extensions["Array.indexOf"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
Array.prototype.indexOf = function(item) {
	for (var i = 0; i < this.length; i++) {
		if (this[i] == item) {
			return i;
		}
	}
	return -1;
};

//============================================================================
// Array.contains Function
//============================================================================
//
// Returns true when the array contains the given item, otherwise false. 
//
// @param item [may be null]
//
version.extensions["Array.contains"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
Array.prototype.contains = function(item) {
	return (this.indexOf(item) >= 0);
};

//============================================================================
// Array.containsAny Function
//============================================================================
//
// Returns true when the array contains at least one of the elements 
// of the item. Otherwise (or when items contains no elements) false is returned.
//
version.extensions["Array.containsAny"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
Array.prototype.containsAny = function(items) {
	for(var i = 0; i < items.length; i++) {
		if (this.contains(items[i])) {
			return true;
		}
	}
	return false;
};


//============================================================================
// Array.containsAll Function
//============================================================================
//
// Returns true when the array contains all the items, otherwise false.
// 
// When items is null false is returned (even if the array contains a null).
//
// @param items [may be null] 
//
version.extensions["Array.containsAll"] = {major: 1, minor: 0, revision: 0, date: new Date(2005,11,20), provider: "http://tiddlywiki.abego-software.de"};
//
Array.prototype.containsAll = function(items) {
	for(var i = 0; i < items.length; i++) {
		if (!this.contains(items[i])) {
			return false;
		}
	}
	return true;
};


} // of "install only once"

// Used Globals (for JSLint) ==============
// ... DOM
/*global 	document */
// ... TiddlyWiki Core
/*global 	convertUnicodeToUTF8, createTiddlyElement, createTiddlyLink, 
			displayMessage, endSaveArea, hasClass, loadFile, saveFile, 
			startSaveArea, store, wikify */
//}}}


/***
!Licence and Copyright
Copyright (c) abego Software ~GmbH, 2005 ([[www.abego-software.de|http://www.abego-software.de]])

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or other
materials provided with the distribution.

Neither the name of abego Software nor the names of its contributors may be
used to endorse or promote products derived from this software without specific
prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
***/

by Alvin Marcelo

The current model right now is an Intranet setup, so for every facility, there will be one desktop assigned as a server and two desktops assigned as workstations. That's the current setup.	We are trying to shift away from that because that's a little time consuming. You have to go to the facility, install the Linux server, put up the network. We're trying to shift to a software as a service model where the minimum is you have three computers on the Internet and then we just give them a URL that they can access, and that URL is specific to their application. It's going to be a virtualized environment so there's no mixing of data between facilities, just for security and their peace of mind. 

I'm idealistic. I wanted to have this system running in remote and rural areas, but in terms of practicality, the rural areas will require the Intranet model. The resources is just too much for an Intranet model, especially if you don't have local tech support available. 
This document gives policy makers, implementors, donors and other health information stakeholders tools and perspectives that will enable them to create excellent electronic health systems. Because every hospital, disease and certainly every country is different, we don't expect anybody to read it from beginning to end. It is designed to allow the reader to follow their interests through the relevant sections of the work.  We think that a minister of health might start with the policy section and follow his or her way into the section on using data effectively. Or the health software developer might start with the section on security and ultimately be led to the section on indicator selection. An excellent electronic health care system requires a large number of people to work together towards a common vision, and to consider topics that they might not be regularly exposed to. This book aims to make that happen. 

Furthermore, we hope that you, the consumer of this book will also give back and be a producer as well. We have done our best to collect the challenges, solutions and pitfalls on the topics that we think are most important. But our experiences are limited and this book and the readers that come after you will benefit by hearing about your experiences as well. 

Each section of this book is organized in the same way. It roughly follows the "pattern language" approach, which means that each section has the same three components: challenges, solutions, and links to other sections. Each section may also provide some discussion questions to start discussions at meetings and conferences. 
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/human_resources.jpg]]

!! The Challenge 
Data collection, input, processing, and analysis is often managed by untrained personnel recruited from public health services. Results are poor data quality, a low level of analysis capacity, and limited feedback that could result in more meaningful information production. This also leads to a high rate of staff turnover and a constant need for training and retraining of data managers. 

In general, being a data technician is not a recognized career within most ministries of health. Hence a low level (salary scale wise) person is trained in an ad-hoc fashion to manage data collection. Salary level is accordingly very low and in general working with data is seen as an un-challenging and un-appealing career. The results are not surprising: low data quality and low accountability/reliability/credibility which leads to low utilization of data/reports for decision making by health service managers and policy makers.      

How can we optimize human resource systems to support health information?

!! The Solution
Data management must become a recognized professional career in public health. Creating clear job descriptions will help managers and policy makers to appreciate the role's importance. This should coincide with attractive salary schemes and clear career development paths.

Of course, good recruiting and human resource descriptions are not enough. Candidates must have the skills necessary to accomplish the job and many countries have limited technical training facilities available. Private and public universities and training institutions have to develop courses which are geared towards  the observed needs/skills of future health information system technicians. Curricula development has to be coordinated between various public health training facilities and Ministries of Health, diplomas have to be accredited/recognized by the Ministry of Education and Health. 

Good human resources practices like performance reviews and incentive schemes will help to further improve the health information system ecosystem.

!! Further Information
[[Training]]
[[Policy and Governance]]

!! Examples for from the Field
Financing of HIS, legislative/budgetary issues, coordination with Ministries of Education,  Ministries of Health, and Civil Service entities, coordinating with regional WHO regional offices  to develop “Medical Data Technician CVs“ and standards .

Type the text for 'ICDx'
[img[http://www.healthmetricsnetwork.info/interoperability/images/ict_assessment.jpg]]

!! Recommended Reading 

!! The Challenge 
It is rare to find a healthcare context that uses no information and communications technology.  Installed systems are often referred to as 'legacy systems'.  Many people view legacy systems as a problem because they are often poorly designed; not collecting useful information.  They can also reinforce inefficient work flow and business rules.  Their advantage is that they may work and an investment has already been made in software, hardware, and training to make these systems function.

!! The Solution 
In order to determine the value of existing systems, an assessment must be done.  This should be an objective assessment of the software, hardware, communications infrastructure and the work flow, information streams and business processes that they represent.  Human resource skills should also be assessed.  These include an assessment of how well individuals understand and operate the existing systems as well as more general skills including understanding of computer operation, data manipulation, analysis, and use of data in their job performance.

The assessment should be done with the view of creating a complete picture of the existing ICT infrastructure that can be used to recommend changes.  Some systems can be kept in place, some will need to be modified, others may need to be replaced completely.  Special attention should be paid to interoperability of the existing systems since this will make it easier to replace parts of systems and to have the resulting structure work together smoothly.

!! Discussion
1. What software, hardware, and communications infrastructure are already in place?
2. How much training do individuals have on the existing systems? What sort of training have they received?

!! Further Information 
[[Business Requirements]]
[[ICT Issues]]
[[Work Flow]]
[[Too Much Data]]
[[Software Selection]]

!! Examples from the Field 
Assessment example from Ethiopia.
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/ict_issues.jpg]]

!! The Challenge 
Information and Communications Technology (ICT) is supposed to make life easier. Things are supposed to be faster, more organized and more efficient. Yet ICT often leads to frustration. Using ICT to facilitate interoperability is fraught with these same challenges. These include issues of human resources, training, support. These challenges are further compounded in a developing country context.

!! The Solution 
Strong ICT leadership by experts who have dedicated resources for providing planning and ongoing support is essential to achieving success with ICT within the health system context.

ICT is a dynamic and highly technical field. In order to derive maximum benefit from ICT an expert needs to be part of the team. This person will need to have dedicated time and other resources like computer equipment and internet access to be able to do the job effectively.

The ICT expert will facilitate the planning process. The ICT planning process (see enterprise architecture) should include lots of time for planning meetings that will result in clear action items and a timeline of activities aimed at achieving tangible goals.

Once ICT systems are in place, the expert or team of experts will need to provide support for it. Often projects get funded, built, and deployed and work for a short time before dying due to a lack of ongoing support. 

Typical support issues that may arise will include training of new staff, handling privacy, security and confidentiality issues, dealing with viruses, fixing problems with the existing system,  and responding to feature requests.

Furthermore, for ICT systems to be successful in developing countries unreliable the very physical issues of unreliable electricity, heat, dust and a general lack of understanding about electronic equipment must be considered.

!! Further Information 
[[Privacy and Confidentiality]]
[[Security]]
[[Human Resources]]
[[Constructive Meetings]]
[[Work Flow]]
[[Enterprise Architecture]]
[[Application Development]]
[[Software Selection]]
Inveneo is an NGO focusing on ICT for developing countries - http://www.inveneo.org/

!! Examples from the Field


[img[http://www.healthmetricsnetwork.info/interoperability/images/identity_management.jpg]]

!! Recommended Reading 

!! The Challenge 
Health information systems and applications need to manage several types of identities for different purposes.  These identities include but are not limited to patients, health workers, applications, machines, locations and facilities. How can so many different identities across so many contexts be easily and safely reused?

!! The Solution 
Complete identity management requires a strategy for all of the following processes: 
* creation of an identity
* describing an identity
* following an identity
* revocation or deletion of an identity

Identities are linked to a specific entity. This can be a person, place, application, or an object. Being able to identify an entity enables:
* authentication of that entity for access to systems or information
* validation of that entity as the source of a message or information. This can be accomplished by using public signatures.
* role based access, which allows for a system to grant a specific level of access when the entity authenticates to that system
* auditing or attribution of activities within a system. Hence it is possible to know who or what is responsible for a given action or piece of collected data.

Different sets of identities can be managed differently, for example, maintaining a list of health facilities with a unique facility identifier for a country or region is a different process than what is used to assign a national level health identifier to all patients or all clients of a particular national or regional health system.

Identities can (but do not necessarily need to) be managed using public key infrastructure (PKI) where every entity is given a set of certificates that store the relevant details.  Public certificates are made available to the whole health system so that any application or system can request them as needed.  Private certificates (essentially private keys) are maintained only by the entity that owns the identity.  Depending on local regulations, it may be necessary to also keep a copy of private keys under escrow with an appropriately mandated authority.  Note that the PKI approach requires an advanced level of technical development and infrastructure in order to work effectively.

Software solutions for implementing different approaches to identity management are well understood and broadly available in both the commercial and open source world.  If you're writing your own directory server or certificate authority, you're doing something wrong.

!! Further Information 
[[Patient Identification]]
[[Security]]
[[Privacy and Confidentiality]]
Lightweight Directory Access Protocol (LDAP - http://en.wikipedia.org/wiki/LDAP)
Public Key Infrastructure - X.509 certificates PKI - http://en.wikipedia.org/wiki/X.509
Single sign-on

!! Examples from the Field 
[img[http://www.healthmetricsnetwork.info/interoperability/images/improving_accuracy_of_data_collection.jpg]]

!! Recommended Reading 
[[Monitoring and Evaluation]]

!! The Challenge 
Life and death decisions are made everyday within the health system. Sometimes the decisions are for individual patients, and sometimes the decisions are policy and planning choices at the government level and affect large  populations.  Data (and sometimes politics and personalities) drive these decisions, but often the data that is used is inaccurate and unreliable. This data, or indicators are our condensed view of the world and determine the actions we take.  It is important that the data that goes into the indicators is timely, complete and accurate.
Often, poor quality data is blamed on the people responsible for collecting the data.  Upon closer inspection and understanding of the process it often becomes clear that the system itself contributes to poor data quality. 

!! The Solution 
Before trying to improve the quality of the data that is being collected we must ensure that we are collecting the right data (and only the necessary data so as to avoid burdening the system... see indicator selection). 

Next, we need to ensure that each data element has a complete, unambiguous definition. A regularly updated data dictionary and an accountable process is a good way to accomplish this. 

We must then design systems that collect this information accurately and reliably. Important factors include application design, work flow, training, and feedback.

Data collection systems that are well designed can both motivate people to do a good job and prevent common sources of error. Many of the topics below provide concrete approaches for improving data quality.

!! Further Information 
[[Data Dictionary]]
[[Too Much Data]]
[[Work Flow]]
[[Training]]
[[Use it or Lose it]]
[[ICT Issues]]
[[Human Resources]]
[[Interoperability]]


!! Examples from the Field 
GSM implementation
PNG RHIS and DX collection (mhs - RHIS worked and why, Dx collection didn't and why)
[img[http://www.healthmetricsnetwork.info/interoperability/images/indicator_selection.jpg]]

!! Recommended Reading 
[[Monitoring and Evaluation]]

!! The Challenge 
Selecting the right indicators means selecting which data can be routinely captured and will provide a clear measure of the impact of a given intervention. Unfortunately, the number of indicators tends to proliferate faster than the ability to collect good quality data. This combined with requirements by the international donor community for data for 'performance-based' reporting makes indicator management challenging.

!! The Solution 
Indicators should be relevant, sensitive and accurate. They are integral part of the monitoring and evaluation process.

Many stakeholders often lead to too many indicators for the program to successfully monitor and evaluate. The "use it or lose it" approach is a simple framework to help with this.

Efforts are underway to develop global and national infrastructure for indicator management. The links below provide references for selected guidelines documents from which countries can select internationally agreed upon indicators. Successful efforts have been made to harmonize indicators in various thematic areas, more work is necessary to provide unambiguous machine-readable indicator definitions to facilitate M&E efforts. Work is underway to produce tools such as indicator and metadata registries that support robust electronic indicator definitions.

Indicator selection requires a process for definition, adoption, and harmonization. Typically, countries establish a Monitoring and Evaluation (M&E) working group to facilitate this process. Without this process in place, fragmented indicator management may persist.

!! Further Information 
[[Use it or Lose it]]

http://groups.google.com/Group/Ixf-Group/Web/Indicator Reference Documents|Guidelines Documents for Selected Indicators
http://www.sdmx.org - Statistical Data and Metadata Exchange (SDMX) Standard
http://groups.google.com/Group/Ixf-Group|Indicator Transmission Format (IXF) SDMX Based Health Indicator Standard

!! Examples from the Field 
UNAIDS reduction of HIV indicators from 450 to 60 by the Monitoring and Evaluation Reference Group (MERG).
/***
|Name|InlineJavascriptPlugin|
|Source|http://www.TiddlyTools.com/#InlineJavascriptPlugin|
|Documentation|http://www.TiddlyTools.com/#InlineJavascriptPluginInfo|
|Version|1.9.4|
|Author|Eric Shulman - ELS Design Studios|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|Insert Javascript executable code directly into your tiddler content.|
''Call directly into TW core utility routines, define new functions, calculate values, add dynamically-generated TiddlyWiki-formatted output'' into tiddler content, or perform any other programmatic actions each time the tiddler is rendered.
!!!!!Documentation
>see [[InlineJavascriptPluginInfo]]
!!!!!Revisions
<<<
2009.02.26 [1.9.4] in $(), handle leading '#' on ID for compatibility with JQuery syntax
|please see [[InlineJavascriptPluginInfo]] for additional revision details|
2005.11.08 [1.0.0] initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.InlineJavascriptPlugin= {major: 1, minor: 9, revision: 3, date: new Date(2008,6,11)};

config.formatters.push( {
	name: "inlineJavascript",
	match: "\\<script",
	lookahead: "\\<script(?: src=\\\"((?:.|\\n)*?)\\\")?(?: label=\\\"((?:.|\\n)*?)\\\")?(?: title=\\\"((?:.|\\n)*?)\\\")?(?: key=\\\"((?:.|\\n)*?)\\\")?( show)?\\>((?:.|\\n)*?)\\</script\\>",

	handler: function(w) {
		var lookaheadRegExp = new RegExp(this.lookahead,"mg");
		lookaheadRegExp.lastIndex = w.matchStart;
		var lookaheadMatch = lookaheadRegExp.exec(w.source)
		if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
			var src=lookaheadMatch[1];
			var label=lookaheadMatch[2];
			var tip=lookaheadMatch[3];
			var key=lookaheadMatch[4];
			var show=lookaheadMatch[5];
			var code=lookaheadMatch[6];
			if (src) { // load a script library
				// make script tag, set src, add to body to execute, then remove for cleanup
				var script = document.createElement("script"); script.src = src;
				document.body.appendChild(script); document.body.removeChild(script);
			}
			if (code) { // there is script code
				if (show) // show inline script code in tiddler output
					wikify("{{{\n"+lookaheadMatch[0]+"\n}}}\n",w.output);
				if (label) { // create a link to an 'onclick' script
					// add a link, define click handler, save code in link (pass 'place'), set link attributes
					var link=createTiddlyElement(w.output,"a",null,"tiddlyLinkExisting",wikifyPlainText(label));
					var fixup=code.replace(/document.write\s*\(/gi,'place.bufferedHTML+=(');
					link.code="function _out(place){"+fixup+"\n};_out(this);"
					link.tiddler=w.tiddler;
					link.onclick=function(){
						this.bufferedHTML="";
						try{ var r=eval(this.code);
							if(this.bufferedHTML.length || (typeof(r)==="string")&&r.length)
								var s=this.parentNode.insertBefore(document.createElement("span"),this.nextSibling);
							if(this.bufferedHTML.length)
								s.innerHTML=this.bufferedHTML;
							if((typeof(r)==="string")&&r.length) {
								wikify(r,s,null,this.tiddler);
								return false;
							} else return r!==undefined?r:false;
						} catch(e){alert(e.description||e.toString());return false;}
					};
					link.setAttribute("title",tip||"");
					var URIcode='javascript:void(eval(decodeURIComponent(%22(function(){try{';
					URIcode+=encodeURIComponent(encodeURIComponent(code.replace(/\n/g,' ')));
					URIcode+='}catch(e){alert(e.description||e.toString())}})()%22)))';
					link.setAttribute("href",URIcode);
					link.style.cursor="pointer";
					if (key) link.accessKey=key.substr(0,1); // single character only
				}
				else { // run inline script code
					var fixup=code.replace(/document.write\s*\(/gi,'place.innerHTML+=(');
					var c="function _out(place){"+fixup+"\n};_out(w.output);";
					try	 { var out=eval(c); }
					catch(e) { out=e.description?e.description:e.toString(); }
					if (out && out.length) wikify(out,w.output,w.highlightRegExp,w.tiddler);
				}
			}
			w.nextMatch = lookaheadMatch.index + lookaheadMatch[0].length;
		}
	}
} )
//}}}

// // Backward-compatibility for TW2.1.x and earlier
//{{{
if (typeof(wikifyPlainText)=="undefined") window.wikifyPlainText=function(text,limit,tiddler) {
	if(limit > 0) text = text.substr(0,limit);
	var wikifier = new Wikifier(text,formatter,null,tiddler);
	return wikifier.wikifyPlain();
}
//}}}

// // GLOBAL FUNCTION: $(...) -- 'shorthand' convenience syntax for document.getElementById()
//{{{
if (typeof($)=='undefined') { function $(id) { return document.getElementById(id.replace(/^#/,'')); } }
//}}}
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/integrated_system.jpg]]

!! Recommended Reading 
[[Interoperable System]]

!! The Challenge 
Two approaches are apparent when designing a national health information system: build (or buy) a single, monolithic integrated system or build a framework of interoperability. How can we weigh these approaches and make an informed decision about which is best?

!! The Solution 
A fully integrated health information system is one where all components and sub components have been adapted so that they are interlinked together from a functional, management, and data perspective.  In effect, they create a "single system".  There may or may not be distinct interface points defined between the various components and several different approaches can be used to link the individual components together from common APIs, messaging buses, data standards, etc.  Advantages to this approach include a potentially (but not always) lower initial cost, potentially easier management of the overall system, and a more global availability of information and functions across the entire system.  There are several disadvantages however.  Such systems often bind the owner of that system to a specific vendor (vendor lock-in).  The level of detail of available information is often lowered for certain areas and overall requirements can impose restrictions on specific components that limit their usefulness to their direct users. (A global set of requirements and restrictions needs to be formulated for the entire user base, rather than have specific requirements so that the needs of individual stakeholders groups can be net).

Unlike in an interoperable system where the interface points are clearly defined, in an integrated system, the onus is on the owner of that system to integrate new components into the existing system.  This integration exercise is specific to the component and the system itself rather than reusable, thus leading to potentially increased resource cost and risk to the owner.

Integrated systems are not better or worse than interoperable ones.  They are different approaches.  They may be less appropriate at the regional or national level than interoperable ones, but may be more appropriate within specific settings such as a district or a large health facility such as a hospital.  

Selecting which approach to take requires a long term resource cost and risk analysis.

!! Further Information 

!! Examples from the Field 
Sao Paulo system
Belize system - http://health.gov.bz/moh/index.php?option=com_content&task=blogcategory&id=39&Itemid=66
[img[http://www.healthmetricsnetwork.info/interoperability/images/international_standards.jpg]]

!! Recommended Reading 
[[Interoperability]]

!! The Challenge 
As technology becomes more integrated into the healthcare system a great diversity of software and systems proliferate. To effectively leverage these systems beyond their local contexts they need to work together. Working together means sharing data and sending reports between systems. What tools exist that can facilitate sharing data and sending reports? How do we know which standard is the right one? Isn't it easier to ignore these complex standards and just build something simple that meets our immediate needs?

!! The Solution 
Sharing data and reports requires a messaging system to exchange data in a manner that defines structure and meaning. Numerous internationally accepted and used standards are listed below. Unfortunately there are many standards and quite a lot of overlap and redundancy among them. 

In theory, adopting international standards seems easy and straightforward. On first glance it appears that someone has already done all of the hard work of figuring out the optimal way of sharing information. In practice, it can be quite difficult to adapt international standards to local use.  There are often many (often subtle) differences in the definitions and other meta data that must be resolved.  In the short term, it may be easier to use local or national standards while the process of harmonization with international standards proceeds.   However, the effort should be made to adopt international standards since this will be a good investment in technologies that will enable interoperability amongst future systems and international organizations. Like many short-term/long-term trade-offs this can be a difficult sell, but staying focused on the big picture of interoperability will help encourage prudent policy making.

It is also important to become an active participant in the development of these standards. This sort of feedback can help make the standards more robust and generally applicable.

!! Further Information 
[[Business Requirements]]
[[Policy and Governance]]
[[Use of Data Standards]]

!!! System Integration 
* Health Level Seven (HL7 - http://hl7.org) - patient level data exchange format.
* Statistical Data and Metadata Exchange (SDMX - http://sdmx.org) - Aggregate data exchange format.
* SDMX-HD (Health Domain) - WHO supported summary data exchange format for health indicators (http://groups.google.com/group/sdmx_hd). 

!!! Vocabularies 
* Logical Observation Identifiers Names and Codes (LOINC) - http://loinc.org
* Systematized Nomenclature of Medicine--Clinical Terms (SNOMED CT) - http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html
* International Classification of Diseases (ICD) - http://www.who.int/classifications/icd/en/

!!! Web standards
* REST - a simple web services API that enable web based applications to gain interoperability - http://en.wikipedia.org/wiki/Representational_State_Transfer

!!! Standards Organizations
* International Organization for Standardization (ISO) - http://www.iso.org
* European Committee for Standardization (CEN) - http://www.cen.eu

!!! Other Resources 
* Standards Wiki - http://www.healthmetricsnetwork.info/site/standards
* Healthcare Information and Management Systems Society (HIMSS) - http://www.himss.org
* American Medical Informatics Association (AMIA) - http://www.amia.org
* International Medical Informatics Association (IMIA) - http://www.imia.org

!!! Organizations Developing International Reporting Standards
* Global Fund to Fight AIDS, Tuberculosis, and Malaria (GFATM) - http://theglobalfund.org
* Presidents Emergency Plan for AIDS Relief (PEPFAR) - http://www.pepfar.gov
* UN General Assembly Special Session on HIV/AIDS (UNGASS) - http://www.un.org/ga/aids

!!! Standards in Telemedicine
* Standards in Telemedicine. Unesco Chair of Telemedicine - http://www.teide.net/Catai/StandardsTelemedicine.pdf

!! Examples from the Field 
UNAIDS case study - How standards streamlined international reporting.
[img[http://www.healthmetricsnetwork.info/interoperability/images/interoperability.jpg]]

!! Recommended Reading 
[[Data for Patient Care]]

!! The Challenge
The world of healthcare is full of systems. Sometimes they are paper based, sometimes they are electronic. They are operated in different locations by different people for different purposes. While the ultimate goal might be improving health, the systems tend to be focused on generating reports, supporting healthcare workers, billing patients, and many other things. Sometimes the systems work with patient level data and sometimes they work with aggregated data and statistics. Most of the time these systems are unable to share information. This results in a lot of data being collected and recollected, or transcribed by hand from printouts or registers, or simply never used. How can these systems be connected to work together?

!! The Solution 
"'Interoperability' means the ability to communicate and exchange data accurately, effectively, securely, and consistently with different information technology systems, software applications, and networks in various settings, and exchange data such that clinical or operational purpose and meaning of the data are preserved and unaltered."1 (From Executive Order of the President of the United States)

In other words, interoperability is about making systems work together. It is about making the health system greater than the sum of its individual parts.

Much is needed in order to create an interoperable system and indeed that is what this document is focused on. 

Data interoperability among electronic systems can be facilitated by adopting international standards for messaging and content like HL7 and SDMX, and SNOMED, ICDx, and others, respectively. The use of data standards does not necessarily make for an effective M&E system. Is the right data being collected (indicator selection)? Is the data being used effectively (data use, monitoring and evaluation)? 

!! Further Information 
[[Interoperable System]]
[[Integrated System]]
[[International Standards]]
[[Monitoring and Evaluation]]
[[Data Use]]
Mirth: open source software for healthcare interoperability - http://www.mirthcorp.com/community/overview
Interoperability: The Key to The Future Health Care System - http://content.healthaffairs.org/cgi/content/full/hlthaff.w5.19/DC1
Towards Data Interoperability: Practical Issues in Terminology Implementation and Mapping - http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_028677.hcsp?dDocName=bok1_028677

!! Examples from the Field 
[[An Interoperability Initiative - Philippines]]
[[Fear Keeps Us Using Paper - Philippines]]
Facility to International Organization data flow with OpenMRS and CRIS applications
Population of CRIS with Measure DHS HIV Survey Indicator Database using the IXF

Consider a sketch similar to: http://www.healthmetricsnetwork.info/handbook/lib/exe/detail.php?id=guidebook%3Atopics%3Ainteroperability&cache=cache&media=guidebook:topics:interoperability.gif
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/interoperable_system.jpg]]


!! Recommended Reading 
[[Integrated System]] 
[[Interoperability]]

!! The Challenge 
A national health system faces the problem of many disparate systems that need to communicate with each other.

!! The Solution 
An interoperable system provides a means for communication and coordination of electronic data between the various domains within a national health system. This approach allows multiple applications (and stakeholders) to work together with a diverse set of tools to form a cohesive national health system. 

Health care systems often consist of a diverse group of health care providers (clinics, hospitals, universities, research projects), donors (governments, NGOs), patients (adults, children, refugees), programs (HIV, TB, malaria, primary care, vaccinations).

Benefits of an interoperable system:

  * Multiple groups and stakeholders can build and use different systems 
  * Different systems can share data [[Data Use]] [[Using Data Standards]]
  * Avoids the problem of being locked into a single system or system provider ([[Integrated System]]). 

It is not uncommon, nor a problem, for redundant systems (different applications that provide the same service) to coexist within an interoperable system.

Insert diagram of the various domains

!! Further Information 

!! Examples from the Field 
Multi-Level Healthcare Information Modelling (MLHIM)
Executive Summary

Introduction

“Keep everything as simple as possible; but no simpler.” – A. Einstein

The Multi-Level Healthcare Information Modelling (MLHIM) approach follows on several years of research and development work to overcome semantic interoperability in complex information environments and especially in healthcare. This work has been carried on across continents and projects but always with the foundation that the proof is in the implementation.

History

MLHIM embraces some general concepts from a variety of standards and specification / software projects, in order to provide for semantic information interoperability across conforming healthcare applications. The most basic concept is one of a common information reference model constrained by components that express domain knowledge in artifacts known as Concept Constraint Definitions (CCDs).
It has been well known for two decades that this approach is a requirement for interoperability.
“From the early 1990s it was recognised that a generic representation is required for the communication of arbitrary health record information between systems, and in Europe this has resulted in a succession of EU sponsored R & D projects and two generations of CEN health informatics standards prior to this International Standard.”   -- ISO/FDIS 13606-1:2007(E) 

However, a solution has remained elusive until now. The MLHIM developers have asked the question; Why? 

The answer is that the existing standards and specifications have not focused on the core ideas of interoperability.  In this overview I will attempt to explain why the MLHIM specifications are different. 

What MLHIM is NOT!
This is an important point to establish first.  Healthcare applications have a wide variety of needs as far as each specific implementation is concerned.  The design of those components should be left to the software engineers tasked with the implementation.  There are design patterns and best practice guidelines from other industries as well as healthcare that apply to these areas.  Remembering that healthcare information is not just about one person.  Yes, the core data collection process should be centered on the patient concerned.  But we live in a global society and responsible, shared healthcare data use will benefit everyone.    

NOT – A Persistence Model
While the MLHIM specifications do not define a certain persistence model. There are some basic concepts that implementers should be aware of when creating their healthcare applications.
Healthcare information is hierarchical
ly oriented. Therefore storage in a SQL database means that the developers will not only need to implement ORM layer but also querying the information is more difficult. The NoSQL family of persistence solutions is growing in popularity and capability. Many such as Riak are highly scalable, highly available and have multiple language APIs. 

NOT - User Interface Definitions
Certainly every user interface to every application is different. However, there are some specific things that can be done to generate some consistency.  It is recommended to use the Microsoft Common User Interface (MS-CUI) concepts. This has been a collaborative work between Microsoft and the National Health Service (NHS) in the UK. The basic concept here is to create a library of widgets using CSS, AJAX, etc. technologies so that they can be reused across applications.

NOT – A Programming Language
The MLHIM specifications are programming language agnostic. The exception being that it must be an Object Oriented language. There are groups creating open source licensed implementations of the reference model so that various developers can boot strap their application development. 

NOT – A Message Specification 
There are several existing message specifications and they all have their own popularity circles.  Since MLHIM applications will need to exist in a healthcare information world consisting of legacy applications for many years to come.  It is designed with the concept of being mappable to multiple message formats.  

NOT - Access & Authorization Specifications
Once again this is an area that is critically important but is well established with best practices and in many cases has legal implications that are specific to a political region.  The requirements in this case should be determined by the implementer. 

NOT – A Terminology/Vocabulary
There are no terminologies or controlled vocabularies in the MLHIM specifications.  The tools and infrastructure to use existing, openly available standards in this area are considered in the MLHIM specifications. Specifically the National Library of Medicine in the USA has the resources to manage and maintain the UTS API.  There are open source implementations for use if desired (ex. A national level) or tools can use the openly available one at the NLM. 

NOT – A Query Language
Query languages are tied to persistence models and information needs.  The correct one should be used for every application. 

NOT - A Governance Body
The MLHIM founders have faith in the grassroots, open source, open content concepts.  Whether they are specifications, software or knowledge models.  We do not believe they need to be owned by a formal body that needs capital maintenance to remain viable.  The goods should stand on their own merit.  They are by default,  owned by each and every contributor equally.  This prevents any monopolization or buy-out on any level.  This, creates sustainability. This is not to say that viable businesses cannot be created based on MLHIM.  In fact just the opposite is true.  Because the core is guaranteed to be always available, always maintained  and always inter-operable. Small businesses everywhere can be started and they can guarantee that their software is inter-operable with every other MLHIM based business; large or small.  
Therefore this approach is not only good for healthcare.  It is good for localized emerging economies that can support local businesses to provide local healthcare applications.  

What is MLHIM?
Okay, enough of what we are not.  MLHIM is a specifications project.  The specifications detail a very broadly defined reference information model that is implemented in healthcare software applications of all types.   The constraint model is expressed as XML Schemas that define the constraints required to narrow the definition of the reference model down to some specific idea or concept. We call these schemas, Concept Constraint Definitions (CCDs).  

As a simple example let us say that our reference model has a class that describes a rectangle.  A CCD might then be created that narrows that definition to a square by constraining all four sides to the same length.  That CCD can then be shared with everyone so they know how I defined a square, based on the reference model.  
That is the simplicity in MLHIM. 


Of course there is a steering group that holds the mailing list passwords, domain names, etc.  They are simply volunteers and can be replaced if they are behaving contradictory to the core concepts of MLHIM.
This is a good place to explain the “lack of governance” criticism that will no doubt arise especially in context of the knowledge models, or CCDs as we call them. 
 First I want to propose a situation to you.  When you are tasked with designing a health information system you will no doubt use components that you trust.  How you determine that trust is going to be specific to the component as well as to your personal knowledge and experience.  If there are components that you cannot satisfy yourself that you trust based on knowledge, experience or recommendation by someone you do trust.  Then you will no doubt test them to determine fitness for purpose.  

The CCDs in a MLHIM system can be thought of as the data model for a particular concept or idea.  They are portable between systems expressed as an XML Schema that defines certain constraints on the MLHIM reference model.    They are only useful when they are available to every entity that needs to share certain information has access to them.  The Healthcare Knowledge Component Repository (HKCR) network is established for this reason.  A HKCR network can be local/regional/national in design.  It can be standalone or be part of the global HKCR.NET network.  This latter situation of course is the sensible one.  
We believe that everyone, everywhere should be able to create CCDs.  Now we also know that most people won't.  We also know that many people will but they will not be very good ones.  But just as there are many reasons that highly qualified people contribute to open source software projects.  Many highly qualified domain experts in healthcare (as well as other domains) will create and share CCDs as long as the pain of entry is not greater than the pleasure of contributing.  
Through popularity and use based on fitness for purpose certain CCDs will rise to the top in usage and will become defacto definitions for certain concepts.  This will naturally differ across cultures and political boundaries. But the point is that there is no top-down control bottleneck and there is plenty of room for multiple definitions of one concept and they will all be valid in their own use.  

This has been a necessarily brief introduction to what is a very complex problem. Not just technically but politically and culturally. I want to invite you to become a co-owner of MLHIM artifacts and contribute where ever possible and as you see fit.   Overview page with a link to the mailing list: https://launchpad.net/mlhim 

Kind Regards,
Timothy W. Cook

  


yy
by Mike McKay

In Malawi we built our HIV ART system to have careful role based access. Registration clerks were allowed to only register patients, only nurses could take vitals signs, and only clinicians could stage patients. As we began to roll the system out we realized that the realities of HIV treatment at rural health clinics was much more haphazard than we had experienced at the clinics in the capital city. In many places clinicians would be non-existent and the nurses would have to do everything, including activities like staging that they weren't supposed to do. Or cleaners would take vital signs. Our role based system didn't allow this, and it hindered healthcare workers in their day to day reality on the frontline of the HIV pandemic. So our well planned role based system needed to be modified. We loosened up the restrictions on which roles could do what, and instead focused on providing interfaces and information that helped them get their job done. Specifically we placed restrictions on workflow - we wanted to make sure that each patient visit was complete, that no patient was allowed to skip a station and receive drugs without submitting to the proper protocols.

I suppose the moral of the story is that role based access is a useful approach, but sometimes realities dictate the need for more flexibility.
/***
|Name:|LessBackupsPlugin|
|Description:|Intelligently limit the number of backup files you create|
|Version:|3.0.1 ($Rev: 2320 $)|
|Date:|$Date: 2007-06-18 22:37:46 +1000 (Mon, 18 Jun 2007) $|
|Source:|http://mptw.tiddlyspot.com/#LessBackupsPlugin|
|Author:|Simon Baird|
|Email:|simon.baird@gmail.com|
|License:|http://mptw.tiddlyspot.com/#TheBSDLicense|
!!Description
You end up with just backup one per year, per month, per weekday, per hour, minute, and second.  So total number won't exceed about 200 or so. Can be reduced by commenting out the seconds/minutes/hours line from modes array
!!Notes
Works in IE and Firefox only.  Algorithm by Daniel Baird. IE specific code by by Saq Imtiaz.
***/
//{{{

var MINS  = 60 * 1000;
var HOURS = 60 * MINS;
var DAYS  = 24 * HOURS;

if (!config.lessBackups) {
	config.lessBackups = {
		// comment out the ones you don't want or set config.lessBackups.modes in your 'tweaks' plugin
		modes: [
			["YYYY",  365*DAYS], // one per year for ever
			["MMM",   31*DAYS],  // one per month
			["ddd",   7*DAYS],   // one per weekday
			//["d0DD",  1*DAYS],   // one per day of month
			["h0hh",  24*HOURS], // one per hour
			["m0mm",  1*HOURS],  // one per minute
			["s0ss",  1*MINS],   // one per second
			["latest",0]         // always keep last version. (leave this).
		]
	};
}

window.getSpecialBackupPath = function(backupPath) {

	var now = new Date();

	var modes = config.lessBackups.modes;

	for (var i=0;i<modes.length;i++) {

		// the filename we will try
		var specialBackupPath = backupPath.replace(/(\.)([0-9]+\.[0-9]+)(\.html)$/,
				'$1'+now.formatString(modes[i][0]).toLowerCase()+'$3')

		// open the file
		try {
			if (config.browser.isIE) {
				var fsobject = new ActiveXObject("Scripting.FileSystemObject")
				var fileExists  = fsobject.FileExists(specialBackupPath);
				if (fileExists) {
					var fileObject = fsobject.GetFile(specialBackupPath);
					var modDate = new Date(fileObject.DateLastModified).valueOf();
				}
			}
			else {
				netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
				var file = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
				file.initWithPath(specialBackupPath);
				var fileExists = file.exists();
				if (fileExists) {
					var modDate = file.lastModifiedTime;
				}
			}
		}
		catch(e) {
			// give up
			return backupPath;
		}

		// expiry is used to tell if it's an 'old' one. Eg, if the month is June and there is a
		// June file on disk that's more than an month old then it must be stale so overwrite
		// note that "latest" should be always written because the expiration period is zero (see above)
		var expiry = new Date(modDate + modes[i][1]);
		if (!fileExists || now > expiry)
			return specialBackupPath;
	}
}

// hijack the core function
window.getBackupPath_mptw_orig = window.getBackupPath;
window.getBackupPath = function(localPath) {
	return getSpecialBackupPath(getBackupPath_mptw_orig(localPath));
}

//}}}

[img[http://www.healthmetricsnetwork.info/interoperability/images/lost_to_followup.jpg]]

!! The Challenge 
Chronic medical conditions and treatments such as tuberculosis treatment or anti-retroviral therapy require regular visits to monitor progress and adjust therapy. This typically means that a patient has to visit a clinic every few months, but could consist of other arrangements, for example through home visits by community health workers.
When a patient stops visiting the facility, after some period of time the patient is referred to being "lost to followup". It is important to quickly and accurately identify patients that are lost to followup in order to return them to proper treatment.  Lost to followup also has an impact on programme monitoring and patient populations.  Lack of clear and consistent definitions around lost to followup can also cause confusion. 

!! The Solution
Developing a precise definition of lost to followup is probably the most critical issue when it comes to interoperability. Some times lost to followup is when a patient has exceeded a certain number of days since they were last seen at the clinic. This works fine when all patients are on the same treatment program and all visit the clinic at regular intervals. This is not an effective approach when some patients are given a one month supply of medication and expected to return in four weeks while others are more stable and may not be back for six months. If the definition states that lost to followup is "has not been to the clinic in three months" then many of the most stable patients will be flagged as lost to followup. A more precise definition then might be "a patient has not been to the clinic within one month of their most recent drug supply running out". This definition is more precise, but requires additional data points to determine a patient's lost to followup state. A more sophisticated lost to followup calculation tends to require an electronic data system so that health care workers are not spending too much time doing complex calculations.

Identifying when a patient is lost to followup is the first step. A patient that is lost to followup needs to be located to find out why they have stopped treatment. Good procedures for patient identification in particular are critical. Patient demographic information like address, age and phone number must be recorded either in an electronic system or in paper registers and kept up to date so that patients can be found. 

The act of going out and finding a patient is often performed by community leaders, community health workers, home based health care providers, expert patient peer groups as well as nurses and clinicians.

Systems must be able to account for patients that transfer out, that die or that successfully complete treatment and are no longer part of the program in order to properly account for their entire population.

!! Further Information 
[[Patient Identification]]
[[Identity Management]]
Aidsmap article about loss to follow-up - http://www.aidsmap.com/en/news/2FEE60BA-1C95-4577-9CB7-B6480FC153B3.asp

!! Getting Started
[[Overview]]

!! Governance 
[[Policy and Governance]]
[[Business Requirements]]
[[Constructive Meetings]]
[[Risk Management]]

!! Monitoring 
[[Monitoring and Evaluation]]
[[Lost to Followup]]
[[Improving Accuracy of Data Collection]]
[[Use it or Lose it]]
[[Work Flow]]

!! Information System Design 
[[Interoperability]]
[[ICT Issues]]
[[Maturity Model]]
[[Enterprise Architecture]]
[[ICT Assessment]]
[[Interoperable System]]
[[Integrated System]]
[[Identity Management]]
[[Patient Identification]]
[[Privacy and Confidentiality]]
[[Security]]
[[Role Based Access]]
[[Application Development]]
[[Capturing Electronic Data]]
[[Software Selection]]
[[Open Source Software]]

!! Reporting 
[[Indicator Selection]]
[[International Standards]]
[[National, International and Donor Reporting]]
[[Vertical Systems]]

!! Resources 
[[Human Resources]]
[[Training]]

!! Data 
[[Data Use]]
[[Too Much Data]]
[[Data for Patient Care]]
[[Operations Management]]
[[Data Dictionary]]
[[Data Warehouse]]
[[Use of Data Standards]]

!! Experiences
[[Proposals without Stakeholders - Philippines]]
[[Developing a System that People Will Use - Philippines]]
[[Targeted Training Using Games - Philippines]]
[[From Intranet to Internet - Philippines]]
[[An Interoperability Initiative - Philippines]]
[[Fear Keeps Us Using Paper - Philippines]]
[[National IDs in the UK - United Kingdom]]
[[Building IT Infrastructure - United Kingdom]]
[[Challenges with Privacy and the Clinical Care Record - United Kingdom]]
[[Using Momentum from Other Projects - Peru]]
[[The Technical Part is not the Challenge - Peru]]
[[Mopping Computers - Malawi]]
[[Choosing Interoperability Instead of Exclusivity - Malawi]]
[[Coding in Country - Malawi]]
[[Learning to be Flexible - Malawi]]


<<tiddler [[redirects]]>>
[img[http://www.healthmetricsnetwork.info/interoperability/images/maturity_model.jpg]]

!! Recommended Reading 

!! The Challenge 
Creating a fully interoperable health system is a long process with a far reaching long term goal. Often the task is so daunting that stakeholders don't know where to start. Sometimes the project has started but there it is difficult to track progress or to begin using existing pieces.  How can we measure progress?

!! The Solution 
A maturity model is a way of describing how far along something has evolved. It works like a long term road map with the eventual goal being to formalize processes, programs and systems. But instead of simply being a path that must be followed in order for eventual success to occur a maturity model affirms that incremental success and progress can occur during early stages.

A typical maturity model defines the following five stages:

1. Initial (chaotic, ad hoc, heroic) the starting point for use of a new process.
2. Repeatable (project management, process discipline) the process is used repeatedly.
3. Defined (institutionalized) the process is defined/confirmed as a standard business process.
4. Managed (quantified) process management and measurement takes place.
5. Optimizing (process improvement) process management includes deliberate process optimization/improvement.

These can also be thought of as a continuum. However, it is not true that one end is focused on simple problem solving, followed by innovation, scaling up and then full interoperability between all involved components.  Maturity is a characteristic of the system as a whole, it reflects an evolution in the extent of introspection and quality improvement activities by the owners/operators of the system.  It is a continuum to the extent that some processes may be at one level while other processes are at another, and that maturity can be lost if institutional memory is lost or processes replaced by less mature ones.

The following is not a maturity model, it is a staged technology model.  Maturity should not be confused with technology.  It is a characteristic of the system as a whole, which includes both humans and technology.  Technology should be appropriate to the capacity and maturity of the system (if you automate a mess, you'll get an automated mess).  [A health oriented interoperable maturity model might be:]

Level 1 – Non-electronic data 
  No use of IT to share information (examples: information on paper shared by mail). 
Level 2 - Machine-transportable data
  Transmission of non-standardized information via basic IT; information within the document cannot be electronically manipulated (fax or PC–based exchange of scanned documents, pictures, or PDF files). 
Level 3 - Machine-organizable data
  Transmission of structured messages containing non-standardized data.  This requires interfaces that can translate incoming data from the sending organization’s vocabulary to the receiving organization’s vocabulary and usually results in imperfect translations because of vocabularies’ incompatible levels of detail (examples: e-mail of free text, or PC-based exchange of files in incompatible/proprietary file formats, HL-7 messages). 
Level 4 - Machine-interpretable data
  Transmission of structured messages containing standardized and coded data.  This is the ideal state in which all systems exchange information using the same formats and vocabularies (examples: automated exchange of coded results from an external lab into a provider’s EMR, automated exchange of a patient’s “problem list”).

!! Further Information 
[[Enterprise Architecture]]

{{:guidebook:topics:wimp.ppt|}}

!! Examples from the Field 

[[Fear Keeps Us Using Paper - Philippines]]
[img[http://www.healthmetricsnetwork.info/interoperability/images/monitoring_and_evaluation.jpg]]

!! Recommended Reading

!! The Challenge 
Good ideas are launched, new programs deployed and interventions implemented, but how do we know when they succeed? How can we measure success? Even when a monitoring and evaluation system is in place to measure success they may measure things that don't really indicate success. Often, there are so many different data elements to measure and collect that the team is overwhelmed with too much data and is unable to do useful analysis and provide meaningful results.

In many cases the measured indicators do help determine when success is happening, but the results are not shared with the people managing the program. This information gap means that the people that might benefit most from the information never see it. 

Another problem is that similar programs monitor and evaluate their programs in different ways, with different success indicators and with different tools. This makes it difficult to compare programs.  Comparing similar programs is a great way to tease out critical success factors.

!! The Solution 
If you don't measure it, you can't manage it. The field of monitoring and evaluation (M&E) is well developed with tools and methods that allow decision makers and stakeholders to measure the success of their activities. Specifically M&E consists of routine tasks to collect, evaluate and act on program indicators in an effort to achieve overall success.

Indicator selection is core to the M&E process, and these indicators should be relevant, sensitive and accurate. Having a large number of stakeholders often leads to too many indicators for the program to successfully monitor and evaluate. The "use it or lose it" approach is a simple framework to help with this. An alternative approach is to derive indicators from existing data for patient care rather than adding additional data collection elements as those systems are rolled-out. 

It is critical that the collected information and reports from the M&E activities is used for the routine management of the program. Often M&E is not integrated with program management but rather used only at higher levels at long intervals.  This reduces the management potential of the information. This can be as simple as sending a copy of the M&E report to a clinic, or something more complex like using the results of the collected to indicators to determine staff pay and bonuses. If data for patient care is used for M&E activities then the analysis done will almost certainly support patient care as well. This sort of data use can create feedback loops that can lead to improved data quality and more effective programs. Indicators will give decision makers the information they need to make adjustments to personnel, resources, activities, and supervision to fine tune the program performance.

In order for these indicators to have meaning between clinics, districts and even countries, the indicators must be clearly defined with accepted standards.  This facilitates interoperability.

M&E should be an integral and ongoing activity throughout the life of the project. 

!! Diagram 
(suggest a circular diagram of indicator collection, use, program change (people, resources, work flow, etc.), and back to indicator collection)

!! Further Information 
[[Indicator Selection]]
[[Too Much Data]]
[[Program Design]]
[[Improving Accuracy of Data Collection]]
[[National, International and Donor Reporting]]
[[Data for Patient Care]]

Global Fund M&E Toolkit - http://www.theglobalfund.org/documents/me/M_E_Toolkit.pdf
World Bank M&E Resources - http://www.worldbank.org/ieg/ecd/
by Mike McKay

Despite wind that is full of dust, and utterly exposed clinics, healthcare workers in Malawi work hard to keep their clinics clean. This means a thorough daily or twice-daily cleaning of the entire premises. Of course, cleanliness reduces infection and increases patient confidence, so it is an important goal for any clinic. Unfortunately, cleaners often have little education, and in Malawi many people had never seen a computer in their life. Hence, when the cleaning began computers would regularly get mopped over with the rest of the floor. When water got into the case, the machine would fail. This is an example of an ICT issue that probably wouldn't happen in a place where people are used to computers, and electrical equipment in general. In Malawi we learned to never put computers on the floor, at the very least they should be raised off of the ground, put up on desks, screwed to the wall, or ideally sealed inside a metal cabinet. 
by Simon Old

Going back to 1992, that's when we first developed an NHS government strategy around information and IT. It was very basic: system integration issues, that management information was derived from operational systems, we started looking through security and confidentiality as another objective was about sharing information across our national health system. That led to some quite significant platforms of what I would call infrastructure. We went for a new format NHS number, a single identifier, because our clinical community was very concerned that if we were moving data around that integrity was paramount and we always knew we were talking about the right person. Two things developed out of that, a new NHS number or identifier and the development of what we called shared administrative registers. It's become what we call now our national strategic tracing service, but really it was a unique number for people and a national directory so that if had a patient in front of you, you could know who this person was, where they came from and when you were communicating with another professional from another part of the NHS, you knew that you had the right person basically. 

We had an NHS number for many many years - ever since it started. When we looked at it we found that there were duplicate numbers, there were quite a lot of problems with its issue and it wasn't in a single format even. So if we were trying to get it to underpin computer systems then we needed to issue a new number. It ended up being a ten digit number. What we found was that hospitals would take your NHS number and handwrite it in their notes, but the computer systems would generate a new number for the hospitals because the old number was a mixture of alphanumerics, which wasn't something that was easy to computerize. That's why we went for the new number, the identifier that suited computer systems. Then we developed an admin register, which as very basic stuff, name, address, date of birth, the number and a way therefore of checking that this is John Smith, yes he's from Leeds he was born in April 1965.
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/national_international_and_donor_reporting.jpg]]

!! Recommended Reading 
[[Indicator Selection]]
[[Interoperability]]

!! The Challenge 
Reports attempt to present useful information to decision makers in a concise fashion. Within the health system context there are so many different uses for the information gathered that each use tends to require their own report. This is particularly true when the reports are at the national, international and donor levels. Creating these reports places a large burden on the stewards of the information. How can we reduce this burden?

Furthermore, there is an inherent tension between an immediate demand for international reporting of summary data and a longer-term goal to develop systems that improve patient care. Because the demands for the international reporting systems come from funding sources, they tend to be prioritized. Is there a way to create the required reports and strengthen patient care?

!! The Solution 
While international agreements and donor reporting requirements require countries to report summary indicators progress has been made in harmonising these indicators. This means that various international organizations like the WHO, the US Government and the Global Fund are working together to ensure that their reporting requirements are not different. The goal is that only one report will be needed to satisfy multiple donors. Implementors can take advantage of this harmonisation by aligning their indicators accordingly. Policy makers, donors, and stakeholders need to ensure that implementors are aware and using these indicators.

While it may appear that there is tension between high level reporting and patient level data, the former can not exist without the latter. Without high quality patient level data it is impossible to have reliable high level reports. Therefore priority must be given to capturing high quality data for patient care.
 
Modern Monitoring and Evaluation systems support importing standard indicator definitions defined at national or international levels. Standard data exchange formats like the WHO SDMX-HD help to promote standard information exchange. Parallel efforts to implement summary Monitoring and Evaluation systems and patient care systems will provide population-based data as the monitoring and reporting infrastructure evolves.
 
!! Further Information 
[[Data Use]]
[[Data for Patient Care]]

!! Examples from the Field 
[img[http://www.healthmetricsnetwork.info/interoperability/images/open_source_software.jpg]]

!! Recommended Reading 

!! The Challenge 
Governments and healthcare providers around the world are building electronic systems for health care. Buying software is expensive, and developing it from scratch even more so. Is there a way that all of this work and expense can be shared thereby enabling even better systems to exist?

!! The Solution 
Open source software is software that does not require paying for a license in order to use. But is is more than just free. Open source software also comes with the source code freely available. Having the source code means that the system is completely open for modification. This means that an open source patient registration system used in Argentina could be downloaded and the software modified to make it work in Armenia. Instead of having to start from nothing, open source software can provide a solid base upon which to build interoperable health systems. Open source software is typically of very good quality as the source code tends to more heavily scrutinized as a result of its open nature. Policies should be put in place and developers should be encouraged to adopt open source software.

Furthermore, when software is developed it should be released as open source. Releasing and publishing software as open source can improve its sustainability if other sites adopt the same software. Open source software that is being developed locally can benefit from being part of a global community of expert software developers and in many cases healthcare information system experts. It is also a good model to match government and donor intentions around intellectual property.

!! Further Information 
[[Application Development]]

Open Medical Record System - http://openmrs.org
Open Source Healthcare Alliance - http://www.oshca.org

!! Examples from the Field 
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/operations_management.jpg]]

!! Recommended Reading 
[[Monitoring and Evaluation]]
[[Indicator Selection]]

!! The Challenge 
Without access to reliable, timely and compatible data from a variety of information sources, managing a health system at a district or national level becomes extremely difficult. Some countries may not have current or accurate data on their health work force, their health services, financial flows or stock management. Without this, waste and ineffective health systems result.

!! The Solution 
Health officers at the district and national level need coherent and accurate data to manage resources within a health system. Data about facilities, patients, and services must be uniquely identified and collected in a usable way. Disparate data sources can be combined and compared for better resource management. For example, comparing overall expenditure to morbidity can help to target critical health needs, or comparing patient information with pharmaceutical ordering can reduce the likelihood of dangerous stock outs or waste from expired medical materials that have been over ordered. The data transfer standards may be individual or aggregate, and may cover a variety of distinct sources within an Health Information System, from EMRs, to pharmaceutical tracking systems, to stock management, to human resources management. 

!! Further Information 
[[Identity Management]]
[[Patient Identification]]
[[Data Use]]

!! Examples from the Field 
TEHIP experience in Morogoro district Tanzania making the funding case for bednets for malaria prevention by using district morbidity and expediture data, DHIS, HIVQual in Uganda, IRIS for HR management, National Medical stores system in Tanzania, PIH pharma ordering in Rwanda
[img[http://www.healthmetricsnetwork.info/interoperability/images/executive_summary.jpg]]

//This document is a product of:
World Health Organization
IER/HSI/HCI
Health Care Informatics Unit
Geneva, Switzerland//

!! What is this document?
This document gives policy makers, implementors, donors and other health information stakeholders tools and perspectives that will enable them to create effective and efficient national scale electronic health information systems.  Because every hospital, disease, country and indeed the individual using this document is different, it has been designed to be responsive to different needs. Hence, it was not designed as a document to be read from beginning to end. Instead it is an extensively hyperlinked (cross referenced) document that encourages the user to follow a uniquely relevant path through the work. We have not tried to provide all of the answers -- an impossible task given the wide range of situations -- but instead raise important questions to consider and provide suggestions on how to arrive at the answers.

!! Governance
National level leadership on interoperability via policy and governance is critical for effecting large scale, sustainable change. This leadership needs to work towards creating a recognized authority that will set priorities, unite stakeholders and ensure that progress is being made.

Large scale mappings of business requirements to application functionality will help a wide array of stakeholders understand the benefits of having an interoperable system. Benefits include improved health care delivery and advanced reporting. In order to bring these stakeholders to a shared vision, many meetings must take place. Constructive meetings require agendas and minutes, include the right people moving towards group consensus and result in individual action. Out of these meetings new programs will be designed according to the decisions created in these meeting. As these programs are implemented they must be carefully managed, monitored and evaluated. Key learnings must be documented and communicated back to the key stakeholders at the government level. (see program design and program management)

As new activities and programs are undertaken a careful assessment of risk is required. A clear analysis of risk will allow stakeholders to manage their risk. Risk management involves identifying, mitigating, and monitoring risks inherent to a system, project or activity. It is an attempt to systematically eliminate surprise, or at least to be well prepared for when they occur.

!! Monitoring
As the stakeholders guide the roll out of activities and programs, monitoring and evaluation tools and approaches will be used to measure impact. Monitoring and evaluation fills in the gap of being unable to manage that which is not measured. Specifically it consists of implementing routine tasks to collect, evaluate and act on program indicators in an effort to achieve overall success. Besides simply measuring success in isolation, monitoring and evaluation activities should facilitate comparison of similar programs both within the country and abroad by adopting international standards. 

Monitoring of systems isn't just useful for measuring success, but also for delivering some very specific health care services. Finding patients who have been lost to follow up is a good example of the importance of creating precise definitions and capturing data that will enable a specific activity - in this case locating patients and getting them back on treatment.

As data is leveraged for more effective monitoring and decision making, the importance of the data's accuracy increases exponentially. Hence improving the accuracy of data collection is important. Making sure that the right data is being collected, that its meaning is clear and that the system themselves facilitate accurate data collection can help. One simple approach for improving the accuracy of data collection is to simply remove all data elements that are not used. Use it or lose it - far too often extraneous data elements are added to monitoring and evaluation requirements, but these additions can jeopardize data quality and all of the decisions that depend on them.

Understanding how data flows from patient to healthcare worker all the way up to policy makers and donors enables further monitoring, management and leverage of data. By creating a visual map of this work flow, these processes may be coordinated and made more efficient and the information can be used effectively throughout all levels of the system.

!! Information System Design
Interoperability is all about making a diverse set of systems work together and ultimately accomplish tasks that could never be done if the systems were isolated. Information systems enable interoperability because of their ability to rapidly move, replicate and process data. 

Successfully using information and communication technology (ICT) to enable an interoperable health system will require expert ICT leadership. The ICT field is a dynamic one that requires lots of planning. Ongoing support and training are critical ICT issues that often get overlooked. Embracing a maturity model can be a good way to move towards robust and efficient ICT management while affirming the potential for incremental success and progress during early stages.

Enterprise Architecture is a well documented and comprehensive method used to improve information systems. With a goal like "improving interoperability" or "implementing electronic health information systems", the enterprise architecture approach provides specific approaches and activities to move from broad vision to a realised system.

A critical step of the design process is an objective ICT assessment of the software, hardware and communications infrastructure. This assessment should result in an understanding of how work flow, information streams and business processes are currently operating.

An interoperable system provides a means for communication and coordination of electronic data between the various domains within a health system. This approach allows multiple applications (and stakeholders) to work together with a diverse set of tools to form a cohesive national health system. An interoperable system is contrasted with an integrated system, where all components and sub components have been adapted so that they are interlinked together from a functional, management, and data perspective. An integrated system is effectively a single system. Integrated systems are typically implemented and supported by a single vendor. Integrated systems may provide a quick path to electronic health data capabilities, but is probably not the right choice for a long term, national scale system.

When designing an information system an identity management scheme is often the right place to begin. Identities requiring management include people, places, applications and more. Management of these entities must include the full life cycle from creation, maintenance to deletion of the entity. These identities can then be used for authentication and access control. Perhaps the most important example of identity management within healthcare is the issue of patient identification. Being able to consistently identify patients across the health system enables greater leverage of any single piece of information about a patient. Algorithms exist to create uniquely identifying numbers which employ mechanisms like checkdigits to avoid error during use. Care should be taken to ensure that patient identification approaches are scalable and don't lead to abuse. 

Patient information must be protected from inappropriate access and use while ensuring that proper continuity of care can be provided and that appropriate reporting and monitoring can still be carried out. Privacy and confidentiality policies should follow fair use principles like accountability, consent, limited use, openness and others. Any patient identification scheme needs to work hand in hand with privacy and confidentiality policies. Security is a related concept, and indeed good security is required for privacy and confidentiality to exist, but it certainly doesn't provide privacy and confidentiality. Security is a more general concept that enables confidentiality, integrity and availability. A security policy should be in place that ensures that all electronic health data is secured according to security best practices. 

With a solid base of identity management, security, privacy and confidentiality a role based access scheme can be created. This scheme will enable the proper level of access for the appropriate people. Creating a role based access scheme depends on a careful definition of who is allowed to do what during various activities.

Most situations will require some new application development. Developers will need to have clear requirements that will help them to create the interfaces that actually enable interoperability. Development should follow proven processes and best practices.

While there are many different electronic health systems, they can generally be categorized into one of three categories when it comes to their approach for capturing electronic data: first, fast and last. "First" is when data is entered by the health care provider during the patient visit. "Fast" is when data is transcribed before the patient leaves the clinic, and last is when it is done after a patient leaves, sometimes even off-site. 

The data collection approach is one of the functional requirements that must be determined when selecting software. Besides functional requirements, existing software should be examined, along with other resources like infrastructure, technical expertise and finances. Working groups can then have constructive meetings to make informed selections.

Open source software is freely available and open to modification. It is usually of a high standard, and can provide a good base from which to develop. Releasing newly developed software as open source can improve long term sustainability and connect software developers into a global team of expertise.

!! Reporting
Reporting systems tend to be the place where the benefits of electronic health systems and interoperability in particular are most apparent. Indicators are the key data points that appear on reports. They should be relevant, sensitive and accurate. It is important to maintain a small number of indicators that can be managed well. There are many international efforts to develop common indicators which will encourage good indicator selection and also enable internationally comparable reports.

Besides indicator selection, international standards can be used for transferring data and reporting formats. While it may require more work at the beginning to adopt international standards, the benefits in the long run for interoperability are important. National, international and donor reporting are all embracing standards, which means that multiple stakeholders are in agreement over what needs to  be present in a report. Monitoring and evaluation systems are adopting these standards as well. Donor driven projects tend to create vertical solutions that don't have a wide ranging impact within the entire health system. However, making sure that these vertical programs deploy good interoperable systems can help the benefits spread to beyond the vertical systems. An example might be a patient registration system that is deployed for HIV care, but used throughout a hospital.

!! Resources
Human resources and training are a key success factor to making an interoperable electronic health system function. Policies need to be put in place, and education systems strengthened so that jobs working with these systems become a significant career path. All of the best practices for human resources management apply as well: job descriptions, performance tracking and incentive schemes.

Training can make the difference between success and failure. Good training requires an appropriately targeted and crafted curriculum. The right mix of trainees and a solid methodology such as training of trainers should also be adopted.

!! Data
Interoperability is only effective in so much as the data that it enables to be shared is used. Using data routinely throughout the health system can improve outcomes and create a positive feedback loop that improves data quality. Too much data, even if it is interoperable, is a problem and places undue burden on healthcare workers. But when well selected data and reports are used not only for aggregated high level reports but also for patient care, the care quality can increase. One example is simply from clinicians being better informed about their patients history. Data can and should be used to inform operations management as well. Procurement systems can be improved and a clearer picture about what is actually happening in a clinic can emerge. Using this data will also contribute to the positive feedback loop of having a data driven culture.

A data dictionary should be used to ensure that definitions for data elements and reports are clear, complete and unambiguous. International vocabularies exist and should be used. Data warehouses are a technical solution that combine data sources and enable fast reporting on huge amounts of data. As electronic health systems grow and more systems are sharing data, a data warehouse will be required to coordinate it all.
<div class='header' macro='gradient vert #FFFFFF #3371A3'>
<div class='headerShadow'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
<div class='headerForeground'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
</div>
<div id='mainMenu'>
<div refresh='content' tiddler='MainMenu'></div>
</div>
<div id='sidebar'>
<div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
<div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
</div>
<div id='displayArea'>
<div id='messageArea'></div>
<div id='tiddlerDisplay'></div>
</div>
/***
|''Name:''|PasswordOptionPlugin|
|''Description:''|Extends TiddlyWiki options with non encrypted password option.|
|''Version:''|1.0.2|
|''Date:''|Apr 19, 2007|
|''Source:''|http://tiddlywiki.bidix.info/#PasswordOptionPlugin|
|''Author:''|BidiX (BidiX (at) bidix (dot) info)|
|''License:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
|''~CoreVersion:''|2.2.0 (Beta 5)|
***/
//{{{
version.extensions.PasswordOptionPlugin = {
	major: 1, minor: 0, revision: 2, 
	date: new Date("Apr 19, 2007"),
	source: 'http://tiddlywiki.bidix.info/#PasswordOptionPlugin',
	author: 'BidiX (BidiX (at) bidix (dot) info',
	license: '[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D]]',
	coreVersion: '2.2.0 (Beta 5)'
};

config.macros.option.passwordCheckboxLabel = "Save this password on this computer";
config.macros.option.passwordInputType = "password"; // password | text
setStylesheet(".pasOptionInput {width: 11em;}\n","passwordInputTypeStyle");

merge(config.macros.option.types, {
	'pas': {
		elementType: "input",
		valueField: "value",
		eventName: "onkeyup",
		className: "pasOptionInput",
		typeValue: config.macros.option.passwordInputType,
		create: function(place,type,opt,className,desc) {
			// password field
			config.macros.option.genericCreate(place,'pas',opt,className,desc);
			// checkbox linked with this password "save this password on this computer"
			config.macros.option.genericCreate(place,'chk','chk'+opt,className,desc);			
			// text savePasswordCheckboxLabel
			place.appendChild(document.createTextNode(config.macros.option.passwordCheckboxLabel));
		},
		onChange: config.macros.option.genericOnChange
	}
});

merge(config.optionHandlers['chk'], {
	get: function(name) {
		// is there an option linked with this chk ?
		var opt = name.substr(3);
		if (config.options[opt]) 
			saveOptionCookie(opt);
		return config.options[name] ? "true" : "false";
	}
});

merge(config.optionHandlers, {
	'pas': {
 		get: function(name) {
			if (config.options["chk"+name]) {
				return encodeCookie(config.options[name].toString());
			} else {
				return "";
			}
		},
		set: function(name,value) {config.options[name] = decodeCookie(value);}
	}
});

// need to reload options to load passwordOptions
loadOptionsCookie();

/*
if (!config.options['pasPassword'])
	config.options['pasPassword'] = '';

merge(config.optionsDesc,{
		pasPassword: "Test password"
	});
*/
//}}}
[img[http://www.healthmetricsnetwork.info/interoperability/images/patient_identification.jpg]]

!! Recommended Reading 
[[Identity Management]]

!! The Challenge 
People appear as patients throughout various parts of the health system throughout their lifetimes and even throughout the course of a particular treatment. If patients are required to re-register every time, and healthcare workers depend on oral histories or carried documents for information, then time is wasted, errors in treatment may occur, patients may get double counted and other problems will occur. How can a patient be consistently identified throughout an interoperable health system?

!! The Solution 
Patient identification enables an interoperable health system to follow patients and more importantly, collect and reuse their data whenever they access health services. 

One of the most fundamental issues in patient identification is the calculation of a unique number or string of characters to associate with each patient. Best practices will include a prefix, version number and checkdigit. A prefix, such as the letter "P", is used so that when an id is read by humans it can quickly be identified as a certain type of identifier - in this case for a patient. A version number will be used to differentiate various versions of an identifier. For instance, an identifier may need to add additional digits to handle more patients. A version digit could be incremented to signal this change and reduce confusion when two patient identifiers of differing lengths or formats are presented. Finally, and arguably most importantly is the checkdigit. A checkdigit is a single digit that is calculated via a simple calculation of all of the preceding numbers. A (too) simple checkdigit scheme might simply add all of the preceding numbers and use the final digit. So if the number was P125, the checkdigit would be 1+2+5 = 8, and the resulting id number would be P1258.  A simple calculation indicates that the number is "internally consistent". Now, imagine that one of those numbers changed: P1268 then the checkdigit won't add up and we know we have an invalid number. This can be a great way for catching transcription errors.

Things to avoid when creating version numbers is using codes or numbers that have inherent meaning. For instance, using the string "NY" to identify patients registering at the New York clinic might lead to people trying to infer information from the patient identifier. Visual identifiers should never be able to indicate what diseases a patient has been treated for. Another potential pitfall is the use of numbers and letters that look similar like 0 and O or Q. These potentially ambiguous characters should be eliminated. 

Tools that can help enable patient identification include barcodes, biometric readers (fingerprint), smart cards, RFID tags, and more.

!! Further Information 
Checkdigits - http://en.wikipedia.org/wiki/Check_digit

!! Examples from the Field 
[img[http://www.healthmetricsnetwork.info/interoperability/images/policy_and_governance.jpg]]
!! Recommended Reading 
[[Use of Data Standards]]

!! The Challenge 
Without national or international governance over health informatics standards around interoperability, differing interpretations of key terms and standards issues will be implemented by different stakeholders.  This may result in loss of data, degraded quality of data, compromised security and confidentiality of personal data, and an increased and inefficient burden of data collection on health care workers.

!! The Solution 
National governments and international organisations should establish clear governance mechanisms over key areas to ensure common usage of interoperability standards.  The creation of a Technical Working Group that can evolve into a mandated government authority on interoperability and related standards is useful to determine which standards should be implemented first and what governance questions need to be asked within a given context for them to be universally adopted and to be useful for their intended purpose.  These areas may  include identity management which includes everything from patient identification to service and facility identification, to defining policies and parameters for role based access, to establishing clear guidance around common minimum datasets for reporting (indicator selection), to technical guidance on the use of data standards that ensure data can be shared in a national health information system in an accurate, timely and safe way.  

!! Further Information 
[[Patient Identification]]
[[Indicator Selection]]
[[Security]]
[[Privacy and Confidentiality]]
UK NHS Information Governance Standards - http://www.dh.gov.uk/en/Managingyourorganisation/Informationpolicy/Informationgovernance/index.htm
US Health and Human Services Policies - http://www.hhs.gov/policies/index.html

!! Examples from the Field 
[[An Interoperability Initiative - Philippines]]

Security, privacy and confidentiality meeting in which the Americans and the Eastern Europeans agreed on the importance of role based access without realizing they meant two opposite things by it
Use of public records to politically target vulnerable population groups in Africa
Consensus building efforts on minimum data sets and indicator selection both locally and internationally in the HIV sector
Differing attempts at creating national identifiers for patient identification with and without using international standards in Africa
Differing governance structures in Canada, Denmark, UK, Brazil and Turkey.  
China wanting to learn more about international data standards in order to create a non compatible national standard to prevent health data from leaving the country.
[img[http://www.healthmetricsnetwork.info/interoperability/images/privacy_and_confidentiality.jpg]]

!! Recommended Reading 
[[Security]]  
[[Patient Identification]]
[[Data for Patient Care]]

!! The Challenge 
Patient information must be protected from inappropriate access and use across a health information system while ensuring that proper continuity of care can be provided to the individual and that appropriate reporting and monitoring can still be carried out in accordance with local, regional, and national policies and requirements.

!! The Solution 
Protecting privacy and confidentiality of patient information relies on solid security.  However, security on its own does not provide privacy or confidentiality protection.

Privacy and confidentiality protection should be designed into systems and applications and, where applicable, infrastructure right from the onset of a project.  Although it is sometimes possible to retro-fit such protections into existing system, this is often more expensive and less efficient than including them in the initial design.

Countries, regions, or districts may often have privacy and confidentiality policies that must be adhered to, however, these may not be explicitly geared for the health sector but still apply.  It is important to identify these early on so that system design can take them into account.  Failure to do so may result in the system being unusable because of legal issues.

In the absence of policies governing the collection, use, and dissemination of personal information, the following fair information principles are a useful start to implement in a system:

* Accountability:  Maintain a clear process and contact point to ensure accountability for how data is collected, used, and disseminated.
* Identifying purposes.  Clearly specify why personal information needs to be collected.
* Consent.  Individuals should be asked for consent in the collection and use of their information.  If the information is to be put to a new use after consent has been given, this new use should be presented to the owner of the information and consent should be given first.
* Limiting collection.  Only collect information that is needed, use it or lose it.
* Limiting use, disclosure, and retention.  Information should be disclosed and retained according to clear policies and destroyed when no longer needed for the specified use.
* Accuracy. If data is being collected then there is a responsibility to make sure it is valid and accurate.
* Safeguards. Implement good security in systems that collect, use, or disseminate personal information
* Openness. Being transparent about the who, what, why, when and where will ensure that privacy and confidentiality don't rely on secrecy, but on solid systems.
* Individual access.  Individuals should have access to the information pertaining to them.
* Provide recourse.  There should be clear and simple mechanisms for individuals to file complaints and corrections to the data pertaining to them. 

The concept of ownership of personal information varies from jurisdiction to jurisdiction.  It is important to identify and clearly communicate who owns and is responsible for specific items of personal information about an individual.  Note that some items can sometimes be tricky, for example, a health care worker's clinical notes about an individual may be "owned" by the health care worker, but specific details in those notes may be "owned" by the patient.

Care must be taken with distribution of reporting data sets as these can inadvertently breach patient confidentiality and privacy by identifying small groups of or single individuals because of boundary values in the sets or unusual combinations of values for common observations. For example, a data set identifying counts of women giving birth in a particular geographic area disaggregated by age and HIV+ could lead to the explicit identification of older individual's HIV status.

There exists methods and algorithms to anonymise personal information as well as to pseudonymise it so that personal information from different sources can be linked without compromising the identity of individuals. 

A well designed patient identification system can be used to support privacy and confidentiality.

!! Further Information 
[[Interim Guidelines on Protecting the Confidentiality and Security of HIV Information (UNAIDS/CDC/WHO) | http://data.unaids.org/Pub/Manual/2007/Confidentiality Security Interim Guidelines 15may2007 en.pdf]]
Principles described in the Canadian Personal Information Protection and Electronic Documents Act (PIPEDA) - http://en.wikipedia.org/wiki/Personal_Information_Protection_and_Electronic_Documents_Act
OECD guidelines on protection of personal information
Office of the Privacy Commissioner of Canada - http://www.privcom.gc.ca
[[UK Department of Health Patient Confidentiality Policy | http://www.dh.gov.uk/en/Managingyourorganisation/Informationpolicy/Patientconfidentialityandcaldicottguardians/DH_4084181]]

!! Examples from the Field 
NHS connecting for health system ground to a halt because of privacy and confidentiality concerns.  Basically, this was not really considered at design time and patients started to complain when consequences of incorrect information started to spread across the system with no means to correct the errors.

New programs must  be designed according to the decisions made and plans created by policy makers.
As programs are  implemented they must be carefully managed, monitored and evaluated. Key learnings must be  documented communicated back to the key stakeholders at the government level.
by Alvin Marcelo

The Community Health Tracking System (CHITS) started about five years ago. We got a grant -- there was a grant that was opened by IDRC Canada for anything -- a small grant program for anything on health informatics. And at that time, I just came back from my fellowship from Bethesda and Herman Tolentino just came back from his postdoc in University of Washington with Sherry Lee Cooler. We thought that is just a nice opportunity to put our minds together and come up with a project where we can show what we have learned. So we submitted a proposal for a child injury tracking system using SMS, so that's actually CHITS, Child Injury Tracking System.

The idea was, the Philippines then was a one billion text messages per day country and many of the midwives had cellphones already. We didn't have an injury tracking systems, not even in the hospitals, so we wanted something at the community level where if there's a child that was injured, they would report it by SMS to a central facility and they would be stocking messages in the machine, the server would parse them into the database, et cetera, et cetera.

The first problem was when we started talking with the potential end users, we found out that these were like, middle aged women and they were operating their cellphones via voice activation, so essentially they weren't really using their cellphones. They were telling their children, "hey, baby boy, why don't you text your older sister and ask her to do this?" So they weren't really holding on to the phones. They were telling their younger people in the family to operate the mobile phones for them, so we thought that was going to be a problem, that they won't be able to text or SMS the injury messages to the server themselves.

The second problem was, when we did some stake-holding with the department of health or the ministry of health in other countries, they were sort of -- they gave us like the cold shoulder because they didn't -- I think they were trying to do something similar as well.

The first problem was, the midwives seemed like they wouldn't be able to use -- to type the proper SMS messages. The second problem there was, they said that these midwives can submit data, but it's not really official data until it becomes the report of the Department of Health. So we thought that a child injury tracking system wasn't going to work. 

I wrote it in a proposal without consulting the stakeholders, and then making wrong assumptions about what the needs are at the ground level. So although we had received the grant money, we were in quite the dilemma. And we thought that we needed to tell IDRC that the original plan will fail and lose face, or we had the option to just do it as we proposed that we would do it and fail anyway, and just fail at the end instead of failing at the beginning. And I think that was a very [important] lesson in health informatics.

So we wrote a letter to IDRC and told them -- well before we wrote the letter to the IDRC we tried to find out from the stakeholders what might work. So we went back to the front line facility health workers and asked them, what their needs were.  We went down to the end users at the facility level and we talked to them more closely. And they said you know what, we need an electronic health record system for our front line health centers. These are what we call rural health units. Or RHUs, these are the government front line health facilities. So we did some stake holding and that's when we learned -- that's when we learned that yeah, this was something that was needed. So we shifted to the community health information tracking system.
/***
|Macro|redirect (alias)|
|Author|[[Clint Checketts]] and Paul Petterson|
|Version|1.1 Jan 26, 2006|
|Location|http://checkettsweb.com/styles/themes.htm#RedirectMacro|
|Description|This macro tells TW to find all instances of a word and makes it point to a different link.  For example, whenever I put the word 'Clint' in a tiddler I want TiddlyWiki to turn it into a link that points to a tiddler titled 'Clint Checketts' Or the word 'TW' could point to a tiddler called 'TiddlyWiki' It even matches clint (which is lowercase) [[Clint]] leet lEEt LEET|
|Usage|{{{<<redirect TW TiddlyWiki>>}}}   |
|Example|<<redirect TW "TiddlyWiki">>  <<redirect Clint "Clint Checketts">> (Nothing should appear, its just setting it all up)<<redirectExact lEEt Elite>>|

!Revisions
1.1- Fixed tiddler refresh so a tiddler declaring a redirect will also render the redirect
1.0- Updated to work with TiddlyWiki 2.0 (thanks to Udo Borkowski)
0.9- Original release October 2005

!Code
***/
//{{{
version.extensions.redirectExact = {major: 1, minor: 2, revision: 0, date: new Date(2005,10,24)};
config.macros.redirectExact = {label: "Pickles Rock!"};
config.macros.redirectExact.handler = function(place,macroName,params,wikifier,paramString,tiddler){
	config.macros.redirect.handler(place,macroName,params,wikifier,paramString,tiddler);
}

version.extensions.redirect = {major: 1, minor: 2, revision: 0, date: new Date(2005,10,24)};
config.macros.redirect = {label: "Pickles Rock!"};

config.macros.redirect.handler = function(place,macroName,params,wikifier,paramString,tiddler){

var redirectExists = false
// Check to see if the wikifier exists
for (var i=0;i<config.formatters.length;i++)
	if (config.formatters[i].name == "redirect"+params[0])
		redirectExists = true;

//If it doesn't exist, add it!
if (!redirectExists){
	for( var i=0; i<config.formatters.length; i++ )
		if ( config.formatters[i].name=='wikiLink') break ;

	if ( i >= config.formatters.length ) {
		var e = "Can't find formatter for wikiLink!" ;
		displayMessage( e ) ;
		throw( e ) ;
	}

var pattern;
	if (macroName == 'redirect'){pattern=params[0].escapeRegExp().replace(/([A-Z])/img, function($1) {return("["+$1.toUpperCase()+$1.toLowerCase()+"]");});
	} else {
		pattern=params[0].escapeRegExp();
	}

	config.formatters.splice( i, 0, {
		name: "redirect"+params[0],
		match: "(?:\\b)(?:\\[\\[)?"+pattern+"(?:\\]\\])?(?:\\b)",
		subst: params[1],
		handler:  function(w) {
			var link = createTiddlyLink(w.output,this.subst,false);
			w.outputText(link,w.matchStart,w.nextMatch);
		}
	});
	formatter = new Formatter(config.formatters); //update the tiddler
	if(tiddler) story.refreshTiddler(tiddler.title,null,true); //refresh tiddler so the new rule is applied
} // End if
}
//}}}
[img[http://www.healthmetricsnetwork.info/interoperability/images/risk_management.jpg]]

!! Recommended Reading 

!! The Challenge 
All activities involve some element of risk.  Some activities are more risky than others. Engaging in activities without being aware of the risks involved can lead to disaster. This is not to say that risky situations or activities must be avoided, because engaging in new risky activities is often the only way progress can be made.

!! The Solution 
Risk management involves identifying, mitigating, and monitoring risks inherent to a system, project or activity. It is an attempt to eliminate surprise or at least be well prepared for problems.

Risk can be roughly calculated as the likelihood of an adverse event occurring times the severity of its impact. This calculation facilitates the prioritization of individually identified risks.

For instance, compare the risk of a deadly accident occurring when a high level official drives to a rural health clinic versus the risk of losing power for a critical lab service that relies on grid electricity.

In the first case, the likelihood of the event occurring might be very small: .01%, but the impact might be estimated at $500,000 (cost of funeral, car, time lost in replacing the position). So the risk would have a value of 50 (0.0001 * 500000).

In the second case, the likelihood could be quite high if the electricity provider is prone to power cuts, say 12% chance of a 15 minute failure every day. The impact might be valued at $10 (samples need to be rerun and use more materials, patients waste time waiting for results). In this case the risk would have a value of 1.2 (0.12*10). 

Once a particular risk is identified, there are four broad approaches to mitigation, or reducing risk:
  * Avoidance, where the risk is eliminated
  * Reduction, where the level of risk is lowered, but it it is not eliminated
  * Transfer, where the risk is transferred to some other entity
  * Retention, where you accept the risk and plan for its eventual occurrence

Which approach to use will depend on the impact of the risk vs the cost to mitigate it to a particular level, as well as the system's or the system owner's overall level of risk tolerance.  Note that one must generally be able to tolerate a certain level of risk, as a zero risk tolerance means than all identified risks are eliminated - a costly and often impossible proposition.

Part of risk management is business continuation planning, an aspect of disaster recover than covers plans for continuing the functions of a system at some level in case of a major failure.

The cost of managing risk must take into account the impact of the risk itself.  For example, it is not worthwhile to eliminate a risk with an estimate impact of $1000 with a $10000 solution, thus the process of risk management must add value.

Project managers and others must be encouraged to identify risks regardless of the overall mitigation strategy.  Even if a risk cannot be managed for whatever reason, it is still better to have identified it and know it as possibility rather than have it strike later as a surprise.

!! Further Information 
[[Security]]
[[ICT Assessment]]

http://en.wikipedia.org/Wiki/Risk_management
http:///www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43170  - Principles and guidelines on implementation"
[[Disaster recovery]]
[[Business continuation]]

!! Examples from the Field 
[img[http://www.healthmetricsnetwork.info/interoperability/images/role_based_access.jpg]]

!! Recommended Reading 

!! The Challenge 
The privacy and security of health information should always be protected.  However, various people involved in patient care and program monitoring need to have access to information.  The specific information and level of detail they need to access depends on the job they are performing or decision that they need to make.  How can we enable secure information access to the right individuals for appropriate activities?

!! The Solution 
The solution is to allow access to specific information on a "need to know" basis depending on their role in the organization.  For example, a person involved in direct patient care would need access to all of the clinical information about the patient he or she is caring for at the time.  They do not need access to demographic or payment information.  They do not need access to any patients other than the one they are seeing.  One could design a "Patient Care" role with these parameters.
Another example would be a facility manager who would need access to information about the number of patients seen each day by each provider of care as well as support services such as lab, x-ray, and ancillary services.  They would not need access to individual patient information but only the specific aggregate information necessary to manage the facility.  A role of "Facility Manager" could be designed with these parameters.

In a similar fashion, all of the potential roles for people accessing information can be defined.  Every individual can then be assigned a role (or more than one role if they have several job functions).  They then log into the computer system and are assigned the data access for their role(s).

!! Discussion
1. Compare and contrast two different roles from a health information context you are familiar with.
2. How do we solve the problem of individuals who fulfill many different roles?

!! Further Information 
[[Identity Management]]
[[Security]]
National Institute of Standards and Technology RBAC page - http://csrc.nist.gov/groups/SNS/rbac/

!! Examples from the Field 
[img[http://www.healthmetricsnetwork.info/interoperability/images/security.jpg]]

!! Recommended Reading 
[[Risk Management]]

!! The Challenge 
Health information applications, systems, and infrastructure need to implement security measures to protect the data and functions managed by these systems from unauthorized and unaudited access and use.  Across the health system, different components and actors must also be able to authenticate each other and communicate securely.
Note that a good security implementation is a basic foundation for providing privacy and confidentiality but on its own does not provide these functions.

!! The Solution 
Security should implement the CIA triad:
* Confidentiality.  Access must only be granted to individuals or roles that are properly authorized
* Integrity.  Information cannot be modified by an individual or role that is not authorized to do so
* Availability.  Information must be made available when it is needed

The ISO/IEC 27002:2005 Code of practice for information security management recommends examining the following during a security risk assessment:
* security policy,
* organization of information security,
* asset management, human resources security,
* physical and environmental security,
* communications and operations management,
* access control,
* information systems acquisition,
* development and maintenance,
* information security incident management,
* business continuity management, and
* regulatory compliance.

From an interoperability perspective, this may lead to adopting the following:
* Security policies across heterogeneous systems (perhaps as part of the enterprise architecture)
* Identity management and access control
* Auditing standards
* Certificates and public key infrastructure
* Link level security (message and data stream encryption)
* Regulatory compliance
* Development standards for software components

It is important to identify security requirements and to develop a threat model against the system, the information it contains and the communications in which it may engage.  This allows the implementation of appropriately scoped security methods for the system as well as clarifying risk management and mitigation plans in cases of security breaches.

Some methods for implementing security:
* Role based access
* Cryptography
* Public key cryptography
* Identity management
* Authenticated access control
* Audit logs
* Digital certificates
* Security policies
* Operational policies
* Application/system/infrastructure policies implemented in software

!! Further Information 
[[Role Based Access]]
[[Privacy and Confidentiality]]
http://en.wikipedia.org/wiki/ISO/IEC_27007
[[Information Security Management: NHS Code of Practice|http://www.dh.gov.uk/en/Publicationsandstatistics/Publications/PublicationsPolicyAndGuidance/DH_074142]]
Certified Information Systems security Professional certification
 
!! Examples from the Field 
/***
|Name|SinglePageModePlugin|
|Source|http://www.TiddlyTools.com/#SinglePageModePlugin|
|Documentation|http://www.TiddlyTools.com/#SinglePageModePluginInfo|
|Version|2.9.6|
|Author|Eric Shulman - ELS Design Studios|
|License|http://www.TiddlyTools.com/#LegalStatements <br>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides|Story.prototype.displayTiddler(), Story.prototype.displayTiddlers()|
|Options|##Configuration|
|Description|Show tiddlers one at a time with automatic permalink, or always open tiddlers at top/bottom of page.|
This plugin allows you to configure TiddlyWiki to navigate more like a traditional multipage web site with only one tiddler displayed at a time.
!!!!!Documentation
>see [[SinglePageModePluginInfo]]
!!!!!Configuration
<<<
<<option chkSinglePageMode>> Display one tiddler at a time
><<option chkSinglePagePermalink>> Automatically permalink current tiddler
><<option chkSinglePageKeepFoldedTiddlers>> Don't close tiddlers that are folded
><<option chkSinglePageKeepEditedTiddlers>> Don't close tiddlers that are being edited
<<option chkTopOfPageMode>> Open tiddlers at the top of the page
<<option chkBottomOfPageMode>> Open tiddlers at the bottom of the page
<<option chkSinglePageAutoScroll>> Automatically scroll tiddler into view (if needed)

Notes:
* The "display one tiddler at a time" option can also be //temporarily// set/reset by including a 'paramifier' in the document URL: {{{#SPM:true}}} or {{{#SPM:false}}}.
* If more than one display mode is selected, 'one at a time' display takes precedence over both 'top' and 'bottom' settings, and if 'one at a time' setting is not used, 'top of page' takes precedence over 'bottom of page'.
* When using Apple's Safari browser, automatically setting the permalink causes an error and is disabled.
<<<
!!!!!Revisions
<<<
2008.10.17 [2.9.6] changed chkSinglePageAutoScroll default to false
| Please see [[SinglePageModePluginInfo]] for previous revision details |
2005.08.15 [1.0.0] Initial Release.  Support for BACK/FORWARD buttons adapted from code developed by Clint Checketts.
<<<
!!!!!Code
***/
//{{{
version.extensions.SinglePageModePlugin= {major: 2, minor: 9, revision: 6, date: new Date(2008,10,17)};
//}}}
//{{{
config.paramifiers.SPM = { onstart: function(v) {
	config.options.chkSinglePageMode=eval(v);
	if (config.options.chkSinglePageMode && config.options.chkSinglePagePermalink && !config.browser.isSafari) {
		config.lastURL = window.location.hash;
		if (!config.SPMTimer) config.SPMTimer=window.setInterval(function() {checkLastURL();},1000);
	}
} };
//}}}
//{{{
if (config.options.chkSinglePageMode==undefined)
	config.options.chkSinglePageMode=true;
if (config.options.chkSinglePagePermalink==undefined)
	config.options.chkSinglePagePermalink=true;
if (config.options.chkSinglePageKeepFoldedTiddlers==undefined)
	config.options.chkSinglePageKeepFoldedTiddlers=false;
if (config.options.chkSinglePageKeepEditedTiddlers==undefined)
	config.options.chkSinglePageKeepEditedTiddlers=false;
if (config.options.chkTopOfPageMode==undefined)
	config.options.chkTopOfPageMode=false;
if (config.options.chkBottomOfPageMode==undefined)
	config.options.chkBottomOfPageMode=false;
if (config.options.chkSinglePageAutoScroll==undefined)
	config.options.chkSinglePageAutoScroll=false;
//}}}
//{{{
config.SPMTimer = 0;
config.lastURL = window.location.hash;
function checkLastURL()
{
	if (!config.options.chkSinglePageMode)
		{ window.clearInterval(config.SPMTimer); config.SPMTimer=0; return; }
	if (config.lastURL == window.location.hash) return; // no change in hash
	var tids=decodeURIComponent(window.location.hash.substr(1)).readBracketedList();
	if (tids.length==1) // permalink (single tiddler in URL)
		story.displayTiddler(null,tids[0]);
	else { // restore permaview or default view
		config.lastURL = window.location.hash;
		if (!tids.length) tids=store.getTiddlerText("DefaultTiddlers").readBracketedList();
		story.closeAllTiddlers();
		story.displayTiddlers(null,tids);
	}
}


if (Story.prototype.SPM_coreDisplayTiddler==undefined)
	Story.prototype.SPM_coreDisplayTiddler=Story.prototype.displayTiddler;
Story.prototype.displayTiddler = function(srcElement,tiddler,template,animate,slowly)
{
	var title=(tiddler instanceof Tiddler)?tiddler.title:tiddler;
	var tiddlerElem=document.getElementById(story.idPrefix+title); // ==null unless tiddler is already displayed
	var opt=config.options;
	var single=opt.chkSinglePageMode && !startingUp;
	var top=opt.chkTopOfPageMode && !startingUp;
	var bottom=opt.chkBottomOfPageMode && !startingUp;
	if (single) {
		story.forEachTiddler(function(tid,elem) {
			// skip current tiddler and, optionally, tiddlers that are folded.
			if (	tid==title
				|| (opt.chkSinglePageKeepFoldedTiddlers && elem.getAttribute("folded")=="true"))
				return;
			// if a tiddler is being edited, ask before closing
			if (elem.getAttribute("dirty")=="true") {
				if (opt.chkSinglePageKeepEditedTiddlers) return;
				// if tiddler to be displayed is already shown, then leave active tiddler editor as is
				// (occurs when switching between view and edit modes)
				if (tiddlerElem) return;
				// otherwise, ask for permission
				var msg="'"+tid+"' is currently being edited.\n\n";
				msg+="Press OK to save and close this tiddler\nor press Cancel to leave it opened";
				if (!confirm(msg)) return; else story.saveTiddler(tid);
			}
			story.closeTiddler(tid);
		});
	}
	else if (top)
		arguments[0]=null;
	else if (bottom)
		arguments[0]="bottom";
	if (single && opt.chkSinglePagePermalink && !config.browser.isSafari) {
		window.location.hash = encodeURIComponent(String.encodeTiddlyLink(title));
		config.lastURL = window.location.hash;
		document.title = wikifyPlain("SiteTitle") + " - " + title;
		if (!config.SPMTimer) config.SPMTimer=window.setInterval(function() {checkLastURL();},1000);
	}
	if (tiddlerElem && tiddlerElem.getAttribute("dirty")=="true") { // editing... move tiddler without re-rendering
		var isTopTiddler=(tiddlerElem.previousSibling==null);
		if (!isTopTiddler && (single || top))
			tiddlerElem.parentNode.insertBefore(tiddlerElem,tiddlerElem.parentNode.firstChild);
		else if (bottom)
			tiddlerElem.parentNode.insertBefore(tiddlerElem,null);
		else this.SPM_coreDisplayTiddler.apply(this,arguments); // let CORE render tiddler
	} else
		this.SPM_coreDisplayTiddler.apply(this,arguments); // let CORE render tiddler
	var tiddlerElem=document.getElementById(story.idPrefix+title);
	if (tiddlerElem&&opt.chkSinglePageAutoScroll) {
		// scroll to top of page or top of tiddler
		var isTopTiddler=(tiddlerElem.previousSibling==null);
		var yPos=isTopTiddler?0:ensureVisible(tiddlerElem);
		// if animating, defer scroll until after animation completes
		var delay=opt.chkAnimate?config.animDuration+10:0;
		setTimeout("window.scrollTo(0,"+yPos+")",delay); 
	}
}

if (Story.prototype.SPM_coreDisplayTiddlers==undefined)
	Story.prototype.SPM_coreDisplayTiddlers=Story.prototype.displayTiddlers;
Story.prototype.displayTiddlers = function() {
	// suspend single/top/bottom modes when showing multiple tiddlers
	var opt=config.options;
	var saveSPM=opt.chkSinglePageMode; opt.chkSinglePageMode=false;
	var saveTPM=opt.chkTopOfPageMode; opt.chkTopOfPageMode=false;
	var saveBPM=opt.chkBottomOfPageMode; opt.chkBottomOfPageMode=false;
	this.SPM_coreDisplayTiddlers.apply(this,arguments);
	opt.chkBottomOfPageMode=saveBPM;
	opt.chkTopOfPageMode=saveTPM;
	opt.chkSinglePageMode=saveSPM;
}
//}}}
[[Contribute]] | [[Download|Download or Print]] | [[Print|Download or Print]]
Interoperability Wiki
[img[http://www.healthmetricsnetwork.info/interoperability/images/software_selection.jpg]]

!! Recommended Reading 
[[ICT Issues]]


!! The Challenge 
Selecting which software to use can be a daunting task. Should it be an interoperable system or an integrated system? Should we buy it or build it? Do we use open source software or proprietary software? Should we hire a local software development firm or use international consultants?

!! The Solution 
A common understanding of any already existing systems (through an ICT assessment), reporting requirements, functional requirements, available technical and financial resources, and ICT issues and infrastructure will inform a strategy for development of an appropriate health information system. Working groups that gather a diverse group of expert stakeholders (ICT, healthcare, public health) should be established to develop business requirements and provide guidance from which to base these decisions.

!! Discussion
1. Create a list of all of the software being used in your context. Include Microsoft Word, the internet - anything that is helping to get the job done. Try and create an exhaustive list and understand the big picture.  Identify the functions performed by each piece of software.
2. What experts should we consider recruiting as stakeholders?
3. Evaluate the suitability of each software system against your [[Business Requirements]].  Could this be done more efficiently by different software?
4. Often the barriers to efficient use are lack of [[Interoperability]] functionality and standards.  What are your interoperability issues?

!! Further Information 
[[Business Requirements]]
[[Monitoring and Evaluation]]
[[Interoperable System]]
[[Indicator Selection]]

!!! Electronic Medical Record Software
* http://openmrs.org
* http://www.openehr.org
* http://worldvista.org

!!! Monitoring and Evaluation Software
* http://www.cdc.gov/epiinfo - data management and epidemiologic analysis
* http://www.census.gov/ipc/www/cspro - Census and Survey Processing System
* http://www.who.int/health_mapping/tools/healthmapper/en - WHO HealthMapper 
* http://www.unaids.org/en/KnowledgeCentre/HIVData/CRIS/cris.asp - UNAIDS Country Response Information System (CRIS) 
* http://www.undg.org/?P=90 UNDG DevInfo 
* http://kids.fao.org - FAO Key Indicator Data System (KIDS) 
* http://en.wikipedia.org/wiki/DHIS - District Health Information Software (DHIS) 
* http://en.wikipedia.org/wiki/Development_Assistance_Database - Development Assistance Database (DAD) 
* http://www.voxiva.com - Voxiva 

http://www.healthmetricsnetwork.org - global partnership facilitating better health information
http://www.cchit.org - Certification Commission for Healthcare IT

!! Examples from the Field 
/***
http://tiddlystyles.com/#theme:DevFire
Author: Clint Checketts
***/

/*{{{*/
body {
 background: #EDEDED;
font-size:12pt;
}
img {
max-width: 600px;
max-height: 400px;
}
/*}}}*/
/***
!Link styles /% ============================================================= %/
***/
/*{{{*/
a,
a.button,
#mainMenu a.button,
#sidebarOptions .sliderPanel a{
 color: #1D65BC;
 border: 0;
 background: transparent;
}

a:hover,
a.button:hover,
#mainMenu a.button:hover,
#sidebarOptions .sliderPanel a:hover
#sidebarOptions .sliderPanel a:active{
 color: #1D65BC;
 border: 0;
 border-bottom: #1D65BC 1px dashed;
 background: transparent;
 text-decoration: none;
}

#displayArea .button.highlight{
 color: #1D65BC;
 background: #4c4c4c;
}
/*}}}*/
/***
!Header styles /% ============================================================= %/
***/
/*{{{*/
.header{
 border-bottom: 2px solid #fff;
 color: #fff;
}

.headerForeground a {
 color: #fff;
}

.header a:hover {
 border-bottom: 1px dashed #fff;
}
/*}}}*/
/***
!Main menu styles /% ============================================================= %/
***/
/*{{{*/
#mainMenu {color: #fff;}
#mainMenu h1{
 font-size: 1.1em;
}
#mainMenu li,#mainMenu ul{
 list-style: none;
 margin: 0;
 padding: 0;
}
/*}}}*/
/***
!Sidebar styles /% ============================================================= %/
***/
/*{{{*/
#sidebar {
 right: 0;
 color: #fff;
 border: 2px solid #1D65BC;
 border-width: 0 0 2px 2px;
}
#sidebarOptions {
 background-color: #4c4c4c;
 padding: 0;
}

#sidebarOptions a{
 margin: 0;
 color: #1D65BC;
 border: 0;
}
#sidebarOptions a:hover {
 color: #4c4c4c;
 background-color: #1D65BC;

}

#sidebarOptions a:active {
 color: #1D65BC;
 background-color: transparent;
}

#sidebarOptions .sliderPanel {
 background-color: #333;
 margin: 0;
}

#sidebarTabs {background-color: #4c4c4c;}
#sidebarTabs .tabSelected {
 padding: 3px 3px;
 cursor: default;
 color: #1D65BC;
 background-color: #666;
}
#sidebarTabs .tabUnselected {
 color: #1D65BC;
 background-color: #5f5f5f;
 padding: 0 4px;
}

#sidebarTabs .tabUnselected:hover,
#sidebarTabs .tabContents {
 background-color: #666;
}

.listTitle{color: #FFF;}
#sidebarTabs .tabContents a{
 color: #1D65BC;
}

#sidebarTabs .tabContents a:hover{
 color: #ff7f00;
 background: transparent;
}

#sidebarTabs .txtMoreTab .tabSelected,
#sidebarTabs .txtMoreTab .tab:hover,
#sidebarTabs .txtMoreTab .tabContents{
 color: #1D65BC;
 background: #4c4c4c;
}

#sidebarTabs .txtMoreTab .tabUnselected {
 color: #1D65BC;
 background: #5f5f5f;
}

.tab.tabSelected, .tab.tabSelected:hover{color: #1D65BC; border: 0; background-color: #4c4c4c;cursor:default;}
.tab.tabUnselected {background-color: #666;}
.tab.tabUnselected:hover{color:#1D65BC; border: 0;background-color: #4c4c4c;}
.tabContents {
 background-color: #4c4c4c;
 border: 0;
}
.tabContents .tabContents{background: #666;}
.tabContents .tabSelected{background: #666;}
.tabContents .tabUnselected{background: #5f5f5f;}
.tabContents .tab:hover{background: #666;}
/*}}}*/
/***
!Message area styles /% ============================================================= %/
***/
/*{{{*/
#messageArea {background-color: #666; color: #fff; border: 2px solid #1D65BC;}
#messageArea a:link, #messageArea a:visited {color: #1D65BC; text-decoration:none;}
#messageArea a:hover {color: #ff7f00;}
#messageArea a:active {color: #ff7f00;}
#messageArea .messageToolbar a{
 border: 1px solid #1D65BC;
 background: #4c4c4c;
}
/*}}}*/
/***
!Popup styles /% ============================================================= %/
***/
/*{{{*/
.popup {color: #fff; background-color: #4c4c4c; border: 1px solid #1D65BC;}
.popup li.disabled{color: #fff;}
.popup a {color: #1D65BC; }
.popup a:hover { background: transparent; color: #ff7f00; border: 0;}
.popup hr {color: #1D65BC; background: #1D65BC;}
/*}}}*/
/***
!Tiddler Display styles /% ============================================================= %/
***/
/*{{{*/
.title{color: #000;}
h1, h2, h3, h4, h5 {
 color: #000000;
 background-color: transparent;
 border-bottom: 1px solid #333;
}

.subtitle{
 color: #666;
 display: none;
}

.viewer {color: #000; }

.viewer table{background: #666; color: #fff;}

.viewer th {background-color: #996; color: #fff;}

.viewer pre, .viewer code {color: #ddd; background-color: #4c4c4c; border: 1px solid #1D65BC;}

.viewer hr {color: #666;}

.tiddler .button {color: #4c4c4c;}
.tiddler .button:hover { color: #1D65BC; background-color: #4c4c4c;}
.tiddler .button:active {color: #1D65BC; background-color: #4c4c4c;}

#tiddlerDisplay{
  background-color: #FFFFFF;
} 

.toolbar {
 color: #4c4c4c;
}

.toolbar a.button,
.toolbar a.button:hover,
.toolbar a.button:active,
.editorFooter a{
 border: 0;
}

.footer {
 color: #ddd;
}

.selected .footer {
 color: #888;
}

.highlight, .marked {
 color: #000;
 background-color: #ffe72f;
}
.editorFooter {
 color: #aaa;
}

.tab{
-moz-border-radius-topleft: 3px;
-moz-border-radius-topright: 3px;
}

.tagging,
.tagged{
 background: #4c4c4c;
 border: 1px solid #4c4c4c; 
}

.selected .tagging,
.selected .tagged{
 background-color: #333;
 border: 1px solid #1D65BC;
}

.tagging .listTitle,
.tagged .listTitle{
 color: #fff;
}

.tagging .button,
.tagged .button{
 color: #1D65BC;
 border: 0;
 padding: 0;
}

.tagging .button:hover,
.tagged .button:hover{
background: transparent;
}

.selected .isTag .tagging.simple,
.selected .tagged.simple,
.isTag .tagging.simple,
.tagged.simple {
 float: none;
 display: inline;
 border: 0;
 background: transparent;
 color: #fff;
 margin: 0;
}

.cascade {
 background: #4c4c4c;
 color: #ddd;
 border: 1px solid #1D65BC;
}
/*}}}*/
In Malawi, Baobab noted several key differences in the overall success of the same system deployed at Dedza District Hospital and Salima District Hospital, likely due to different training approaches used at each site. At Dedza, Baobab worked with the Lighthouse to offer a comprehensive training program that included all staff certified by MOH to provide ART care and treatment at that site, not just active ART clinic staff. Participants included the DHO. All of the Dedza staff were brought to Lilongwe for one day to visit the Martin Preuss Centre and to observe how the system is currently working.
At present, new users are trained by their peers to a reasonable standard, and there is an overall feeling of ownership of the system.
At Salima, much less effort was put into training. On-the-job training was provided to only the clerks, nurses and clinicians that would actually use the system.
The result was that users at Salima reported relatively more problems during the pilot. The specific issues included:
Incomplete patient records: time pressure, technical issues or user confusion resulted in incomplete entry of nurse visit or drug visit records
Unregistered patients: patients visited on non-clinic days and were seen by untrained staff
Transfer-In patients: patients who were transferring-in were registered before being given drugs
Hop-in Hop-out patients: patients were being registered twice because they had transferred out and then transferred in again
Dual-entry: staff complained about the extra work of entering data in the master card as well as the electronic system
Baobab has worked with the Salima staff to resolve these issues, and all parties have agreed on a plan to improve data quality and ensure consistent system use.
These problems were largely confined to Salima, while Dedza has encountered far fewer problems.
by Alvin Marcelo

There's a lot of problems with introducing technology, especially in health center facilities in the Philippines, where it's possible health workers haven't used computers the whole of their lives. 

So can you imagine taking them from not having touched a computer their whole life and they're in their 40's and 50's and asking them to use a computer right there and then, instantly? For something they have to do on a daily basis. And we have a program and we're proud of that program because it's worked very well. 

Imagine these are old women, never touched a computer their whole lives. So they were saying that CHITS was difficult to use, but actually it was really that they couldn't handle the mouse and the keyboard very well. 

So learning from that we just decided: No CHITS until you can play Solitaire by yourself and you can beat your other co-worker with the highest score in Tetris or whatever. So we eliminated the interface problem. We wanted to make sure that there was no interface problem before we showed them the application. I think that's important.

On the actual training, this is after the two to four weeks interface exercise, we don't let them use the application immediately. We make sure that we have a proper orientation about the value of good quality, that it would be accurate, timely, legible, complete and useful things like the WHO definition. 

The computer is now the tool to help them come up with their quality data. We have to link it from their analysis of the current situation where their data are inaccurate, delayed illegible so forth and so on and then bring them to a understanding that the computer is now the tool that helps them solve many of those poor quality data issues. That gets them to understand why these [people] are introducing computers into the facility in the first place. We thought that was important because unless they understand that it will always be an externally driven motivation rather than an internal motivation that was coming in from their own understanding and analysis of why they need technology to improve their systems.

We spend half a day to one day doing that. We use games to introduce the concepts. I will try to send you a URL of one particular video of that game. It's just a game but in the post game processing and analysis the concepts of system integration come to play: teamwork and communication. Thats where we bring them to the understanding of why computerization for your facility is the most logical way to go if you want to [improve] quality. After that is the time that we introduce the application because now they know why they need to learn the application. As a matter of fact they know that they will have difficulty using the application because in the games they had difficulty playing them at first and the lesson from the games is, "hey this is something new you're supposed to have difficulty at first". So it's not like when you immediately expose them to the application and they have difficulty they don't have handles or they don't have the coping mechanisms to understand why they have to suffer through all of the difficult mode use like registration and child care. So by creating that awareness and orientation on the importance of good quality data and role of computers in good quality data they're more emotionally and attitudinally ready for the stress that follows which is the learning of how to use the application we really can't remove the stress because it's a new system. What we try to do is to give them the defense mechanisms early on in the program so that than we eventually come to the point where they will use CHITS they already have the defense mechanism and the coping mechanisms to understand why they have to go through all of these difficulties. From then on it's downhill. 

Actually the younger ones are more advanced. Some of the older ones are really hopeless, yet they help each other and it really builds confidence because they never thought [that they would ever learn to use a computer]. Many of them tell us thank you very much or "Doctor Alvin, you know I didn't even know that I could actually use a computer". Some of them have actually attended classes already on how to use Microsoft Word, how to use Microsoft Excel, or how to do power point slides.  But they quickly forget it because in the end when they go back to the facility they don't use those programs. They don't type documents, they don't maintain spreadsheets and they don't do power point slides but with CHITS right after the training they go back to the facility and start using the electronic health record and almost every five minutes you have to interface with the system because you have to record the services that you have provided for the patient. 

So we thought that that was something that we didn't want to do. We didn't want to give them any new computer skills that were not related to the work that they are supposed to do. So that's our experience of training and were bundling our training program into a package. The reason we're doing that is because their is so much interest already in electronic health records and in CHITS and I think I need to train more and more trainers to be able to scale up.

We have a lot of good stories on training because I think it was something that we did on top of the software. I don't really think it's like super software. It's not bad software, but it's not like MATLAB or anything like that. It's just a simple database, actually. 

I think it's the training and the capacity building that got it in for CHITS. Not to detract any credit for Herman who developed the source code, but I think that the training program that came out of the software, I think that's the real value that we have right now. I think the software is going to change. We don't have AJAX in the old version, I think we should have AJAX in the new version, and things like that. 

The training program, I think it will stick. 
by Joaquin Blaya

We didn't use any data standards for the lab - loinc or anything - to communicate with the other systems. Probably the most interesting interoperability experience that I have is that the national institute of health, the reference lab, implemented their own lab information system. They wanted our system to communicate with their system. What I found was that apart from the technical difficulties there was reticence between the different levels in order to get access to their information. Which I think is pretty common. 

Some of the reasons for not sharing information was lack of trust, probably issues that are fairly common. The one that I found most common was lack of data in trust of using that data appropriately. The second was feeling that they were going to be monitored by someone that didn't have jurisdiction over them. The Peruvian lab structure, a local lab is under the national reference lab in terms of standards, but they actually get their funding from the local district, so in the end they are really more responsive to the district. This kind of unclear power structure is acceptable, but who do you share data with? Then it becomes more clear that they don't want to share data with their technical partners but they could share data with their funding organization. Anybody who tells you that the hardest part of this thing is the technical part hasn't had much experience.
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/too_much_data.jpg]]
!! Recommended Reading 

!! The Challenge 
Health information systems often lead to a huge mount of data collection forms. Much of the data collected for a patient is redundantly recorded as many forms duplicate fields. Not only does this make a mess for data managers, but it also is an inefficient use of human resources, particularly for clinicians.

Sadly most of the data never even appears in a report or is used for any purpose whatsoever. These “data-graveyards” are a pertinent problem that absorb IT storage capacity and human resources. Huge amounts of mostly unused data makes it more difficult to find useful information in these databases.

!! The Solution 
Centralized policies for routine data collection requirements and reporting can help reduce these problems. Core indicators should be identified that are needed for management, reporting and supervision. Knowing what these core indicators are will then allow a reduction in the number of forms and data elements on forms, and in general help to concentrate on basic data requirements. A “paper work reduction initiative” can be a good mechanism for fighting the problem of too much data.

This “less is more” approach will keep staff from wasting time on unnecessary work filling out forms and performing data aggregation procedures. 

Interoperability opportunities can improve synchronization between data sources either within a hospital or even countrywide. An operational data warehouse may become a critical technical component of the interoperability solutions.

!! Further Information 
[[Use it or Lose it]]
[[Indicator Selection]]
[[Monitoring and Evaluation]]
[[Data Use]]
[[Improving Accuracy of Data Collection]]
[[Human Resources]]
[[Training]]

!! Examples from the Field 
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/training.jpg]]

!! Recommended Reading 
[[Human Resources]]

!! The Challenge 
Interoperable systems require many different human resources: users, operations managers, programmers, support staff. How can we train these positions to get the most out of these human resources?

!! The Solution 

Proper training can make the difference between success and failure of any system component as well as the system as a whole. Issues to be aware of when developing any sort of training include: curriculum, trainee selection and methodology.

The curriculum must be properly targeted. This means that the curriculum should assume the right level of prerequisite knowledge of trainees. Getting this right requires a clear picture about how much experience and knowledge the existing trainees have. Furthermore the curriculum must provide enough material to ensure that upon completion the trainee can do the tasks required of them.

Trainees should be selected to ensure that important stakeholders, sometimes even those that will not use the system are included. Training non-users who might benefit from having a successful system help to ensure champions and organizational buy-in.

Specific training methodologies are beyond the scope of this pattern, but some approaches to consider include:

  * training of trainers
  * peer learning / on the job training
  * conferences

Simple monitoring and evaluation techniques should be performed to understand the effectiveness of the trainings and to enable improvement. This can be facilitated by using exams and by gathering feedback from trainees.

!! Further Information 
[[Use of Data Standards]]

!! Examples from the Field 
[[System Training in Malawi]]
[[Targeted Training Using Games - Philippines]]
/***
|''Name:''|UploadTiddlerPlugin|
|''Description:''|Upload a tiddler and Update a remote TiddlyWiki |
|''Version:''|1.2.2|
|''Date:''|2008-09-13|
|''Source:''|http://tiddlywiki.bidix.info/#UploadTiddlerPlugin|
|''Usage:''|Uses {{{<<uploadOptions>>}}}<br>with those UploadTiddler Options : <br>chkUploadTiddler: <<option chkUploadTiddler>><br>txtUploadTiddlerStoreUrl: <<option txtUploadTiddlerStoreUrl>><br>chkUploadTiddlerFromFile: <<option chkUploadTiddlerFromFile>>|
|''Author:''|BidiX (BidiX (at) bidix (dot) info)|
|''[[License]]:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
|''CoreVersion:''|2.3.0|
***/
//{{{
version.extensions.UploadTiddlerPlugin = {
	major: 1, minor: 2, revision: 2, 
	date: new Date("2008-09-13"),
	source: 'http://tiddlywiki.bidix.info/#UploadTiddlerPlugin',
	author: 'BidiX (BidiX (at) bidix (dot) info',
	coreVersion: '2.3.0'
};

if (!window.bidix) window.bidix = {}; // bidix namespace
bidix.debugMode = false;
bidix.uploadTiddler = {
	messages: {
		aboutToSaveTiddler: "About to update tiddler '%0'...",
		aboutToRemotelySaveTiddler: "About to REMOTELY update tiddler '%0'...",
		storeTiddlerNotFound: "Script store tiddler '%0' not found",
		tiddlerSaved: "Tiddler '%0' updated in '%1' using '%2' "
	},
	upload: function(title,tiddler,oldTitle) {
		var callback = function(status,params,responseText,url,xhr) {
			if (xhr.status == 404) {
				alert(bidix.uploadTiddler.messages.storeTiddlerNotFound.format([url]));
				return;
			}
			if ((bidix.debugMode) || (responseText.indexOf("Debug mode") >= 0 )) {
				alert(responseText);
				if (responseText.indexOf("Debug mode") >= 0 )
					responseText = responseText.substring(responseText.indexOf("\n\n")+2);
			} else if (responseText.charAt(0) != '0') 
				alert(responseText);
			else 
				displayMessage(bidix.uploadTiddler.messages.tiddlerSaved.format([params[0], params[1], params[2]]));
				store.setDirty(false);
			}

		if ((config.options['chkUploadTiddler']) && 
				((document.location.toString().substr(0,4) == "http") || config.options['chkUploadTiddlerFromFile'])) {
			clearMessage();
			if (document.location.toString().substr(0,4) != "http")
				displayMessage(bidix.uploadTiddler.messages.aboutToRemotelySaveTiddler.format([title]));
			else
				displayMessage(bidix.uploadTiddler.messages.aboutToSaveTiddler.format([title]));
			var ExtTiddler = null;
			var html = null;
			if (tiddler) {
				ExtTiddler = store.getSaver().externalizeTiddler(store,tiddler);
				html = wikifyStatic(tiddler.text,null,tiddler).htmlEncode();
			}
			var form = "title="+encodeURIComponent(title);
			form = form + "&tiddler="+(ExtTiddler?encodeURIComponent(ExtTiddler):'');
			form = form + "&html="+(html?encodeURIComponent(html):'');
			var filename = (config.options['txtUploadFilename']?config.options['txtUploadFilename']:'index.html');
			form = form +"&oldTitle="+encodeURIComponent(oldTitle);
			form = form +"&fileName="+encodeURIComponent(filename);
			form = form +"&backupDir="+encodeURIComponent(config.options['txtUploadBackupDir']);
			form = form +"&user="+encodeURIComponent(config.options['txtUploadUserName']);
			form = form +"&password="+encodeURIComponent(config.options['pasUploadPassword']);
			form = form +"&uploadir="+encodeURIComponent(config.options['txtUploadDir']);
			form = form +"&debug="+encodeURIComponent(0);
			var storeScript = (config.options.txtUploadTiddlerStoreUrl 
								? config.options.txtUploadTiddlerStoreUrl : 'storeTiddler.php');
			var r = doHttp("POST",storeScript,form+"\n",'application/x-www-form-urlencoded',
				config.options['txtUploadUserName'],config.options['pasUploadPassword'],callback,Array(title,filename, storeScript),null);
		}
	}
}
TiddlyWiki.prototype.saveTiddler_bidix = TiddlyWiki.prototype.saveTiddler;
TiddlyWiki.prototype.saveTiddler = function(oldTitle,newTitle,newBody,modifier,modified,tags,fields,clearChangeCount,created) {
	var tiddler = TiddlyWiki.prototype.saveTiddler_bidix.apply(this,arguments);
	var title = (newTitle?newTitle:oldTitle);
	if (oldTitle == title)
		oldTitle = '';
	bidix.uploadTiddler.upload(title, tiddler, oldTitle);
}
TiddlyWiki.prototype.removeTiddler_bidix =TiddlyWiki.prototype.removeTiddler;
TiddlyWiki.prototype.removeTiddler = function(title) {
	TiddlyWiki.prototype.removeTiddler_bidix.apply(this,arguments);
	bidix.uploadTiddler.upload(title, null);
}

//
// Initializations
//

bidix.initOption = function(name,value) {
	if (!config.options[name])
		config.options[name] = value;
};

// styleSheet
setStylesheet('.txtUploadTiddlerStoreUrl {width: 22em;}',"uploadTiddlerPluginStyles");

//optionsDesc
merge(config.optionsDesc,{
	txtUploadTiddlerStoreUrl: "Url of the UploadTiddlerService script (default: storeTiddler.php)",
	chkUploadTiddler: "Do per Tiddler upload using txtUploadTiddlerStoreUrl (default: false)",
	chkUploadTiddlerFromFile: "Upload tiddler even if TiddlyWiki is located on local file (default: false)"
});

// Options Initializations
bidix.initOption('txtUploadTiddlerStoreUrl','');
bidix.initOption('chkUploadTiddler','true');
bidix.initOption('chkUploadTiddlerFromFile','');


// add options in backstage UploadOptions
if (config.macros.uploadOptions) {
	if (config.macros.uploadOptions.options) {
		config.macros.uploadOptions.options.push("txtUploadTiddlerStoreUrl","chkUploadTiddler", "chkUploadTiddlerFromFile");
	}
}

//}}}

[img[http://www.healthmetricsnetwork.info/interoperability/images/use_it_or_lose_it.jpg]]

!! Recommended Reading 
[[Monitoring and Evaluation]]

!! The Challenge 
Systems are often designed by multiple stakeholders who each have their own data needs. As a result it is common for data to be collected but never used. This places a burden on the system and that often leads to poor outcomes.

!! The Solution 
Despite this topic's name, the solution is not to figure out how to use all of the data that is collected but rather how to 'lose' extraneous ones.

If a data element is not being used it should be eliminated and not collected. By eliminating unused data elements more time and care can be spent collecting, analyzing and using the data. 

While this sounds like a simple approach, in practice it can be quite difficult. Stakeholders will argue that someday they will analyze the data and that it will be very useful. It can be helpful to remind stakeholders that extra data for research purposes can be collected via statistically significant surveys. It is better to have fewer data elements of high quality than many that are unreliable.

It may also be difficult to eliminate extraneous processes at the clinic level. If healthcare worker has "always done it that way", then they may need careful convincing or at least a direct order from their manager. 

!! Further Information 
[[Data Use]]
[[Indicator Selection]]
[[Too Much Data]] 
[[Improving Accuracy of Data Collection]]

!! Examples from the Field 
[[Story About VCT Data in Malawi]]
 
[img[http://www.healthmetricsnetwork.info/interoperability/images/use_of_data_standards.jpg]]

!! Recommended Reading 
[[Data Use]]

!! The Challenge 
Applications within a national health system are usually built by different organizations for different stakeholders. It is critical that these different applications share data, but creating policies, protocols and interfaces for transferring data between these applications is a tedious process.

!! The Solution 
International standards for data already exist that provide consistent and usually sufficient means for transferring data between most types of health applications. When applications need to share data, they should be chosen or developed so that they that implement and use data standards. Adopting data standards is not only an efficient approach to solving problems, it also helps applications follow conventions that are based on best practices learned elsewhere.

Data standards can address issues of how to:

* store patient data
* transfer lab information
* transfer aggregate indicators
* structure reports

When selecting which data standards to use it is critical to consider how that data will be used. For example, if data is used only to generate aggregate reports you would probably use a different data standard than if the data was used for patient care.

!! Further Information 
[[Application Development]]
[[International Standards]] (contains links to many standards)

!! Examples from the Field 
by Joaquin Blaya

This was in Lima, Peru. The smaller project was using handhelds to get from different health centers and bring them back to the larger center and get them into EMRs. The second one, the one we should talk about is a larger web based system where the labs within the Ministry of Health would enter their information and that would get communicated to the health centers so that the clinicians and the nurses would be able to see the data.  

There was a group from the CDC, Harvard, and the Ministry of Health in Peru, that were doing this project to implement a new lab technique for TB in labs. That involved expanding the labs, physically making them bigger, training people and they had been working on it for a couple of years. If they just got a new technique into the lab there would still be all kinds of problems. But, the reason to get this technique in was because it was faster. Instead of taking four months it took three weeks. But, there were a lot of delays, and not just around this particular technique. So they purchased cars for transportation so that the lab could go pick up samples. They also wanted to put in an information system to reduce the delays from when the result was out until it was given to the clinicians. 

So that's where my project came in - building an information system to make this happen. Therefore being a part of this bigger project was one of the key reasons for success in this project. Since then the information system has taken off and become larger than the project. Other labs are using it, other health centers are using it, that weren't involved in the initial project. In that sense IT systems are easier to expand than laboratory capacity. 

The thing that was reinforced was that in general information systems shouldn't be implemented by themselves but they should be implemented within a larger infrastructure. In general, in developing countries there are many needs that need to be met, information systems being one of them. It is a parallel to a health program. If you cure malaria, but there isn't enough food, or the water is bad, then there is almost no point in curing the malaria. It's almost a parallel to information systems, where we found my project was within a larger project to increase lab capacity and I think one of the reasons that this information system was successful was because there was a larger project that was building labs, performing training to healthcare personnel. And probably the most important thing was that the local officials were already on board in this larger project. We had meetings with everybody from the vice minister of health to the local clinician, but they already had a context as to what was going on. The information system was part of that context.
[img[http://www.healthmetricsnetwork.info/interoperability/images/vertical_systems.jpg]]

!! Recommended Reading 
[[National, International and Donor Reporting]]

!! The Challenge 
International reporting often focuses on a single disease or focus (like maternal health) resulting in vertical reporting systems. While addressing the needs of a particular program, integration of data and overall health system strengthening can suffer. For example, AIDS programmes have been criticized for diverting resources from other equally serious diseases. How can we strengthen the overall health system while acknowledging that particularly serious problems will be prioritized?

!! The Solution 
A growing acknowledgement of the potential adverse impact of vertical systems has led to development of 'horizontal' system strengthening where vertical programmes also support health system strengthening. Efforts have been made to incorporate activities beneficial to overall health and monitoring system strengthening such as health data standards, software development, and harmonization of indicators to address this.

By adopting interoperable architectures horizontal system strengthening may occur as well. For instance, a good patient identification scheme is not disease dependent and can be used to track inpatient care at a hospital. These kind of horizontal value adds may need policy making or general awareness building in order to elicit widescale adoption.

!! Further Information

!! Examples from the Field 
PEPFAR support for vertical health system strengthening.
!! Recommended Reading 

!! The Challenge 
Where and how do you start in working with interoperability within the health information system?

!! The Solution 
First identify your immediate business needs and drivers as well as your initial entry point into the health information system.  For the purposes of this pattern, this is that aspect of the health information system that makes the most sense to deal with first in terms of impact across the system, greatest need, available funding, executive support and likelihood of success.  It can range from clinical admissions of patients, to national drug stock management, to management of lab data to reporting of indicators and so on.

Once this entry point has been identified it must be put into context so that it is clearly understood how it interacts with the health information system.  What are the connection points? what kinds of information is exchanged and how?  who are the entities involved in managing it? what are the governance and policy issues around that concern the entry point?[[Enterprise Architecture]] approaches can help to define this context.

Defining this context around the entry point will lead to the identification of the interoperability issues that need to be addressed from a technical, resource, and governance/policy perspective.  As these are addressed, you can work your way outwards to cover more and more of the health information system in a systematic and orderly way. 

Usually a good idea to create a [[Technical Working Group]] to manage and coordinate issues around this process

Prioritization


!! Further Information 
[[Enterprise Architecture]]
[[Technical Working Group]]

!! Examples from the Field 
The development of the health informatics working group in Malawi?
[img[http://www.healthmetricsnetwork.info/interoperability/images/work_flow.jpg]]

!! Recommended Reading 
[[Data Use]] 

!! The Challenge
A health system, and an interoperable system in particular, consists of many different people and processes capturing and using information for many different purposes. Coordinating these processes so that they are efficient and the information is leveraged appropriately throughout the system is a large and complicated process.

!! The Solution 
The key driver for interoperable systems is the compelling use of data in a different context.  Data collected and shared for its own sake or without a clear use is not likely to serve a real purpose or have any built in incentive to be timely or of quality. A lack of interoperability prevents data from being available for specific tasks within a given work flow.

The first step to understanding existing work flows is to create a map of how information flows through the system being scrutinized. For example, by examining who needs whose data to accomplish what essential tasks, critical interoperability issues and junctures become apparent. This map can also help eliminate redundant data collection.

As this map develops it becomes clear how to distribute the data collection processes and how to included feedback loops that make sure data is being used to its full potential. The key work flows, the paths of really critical information will also become evident and can be prioritized.

Finally, this high level view can make it easier to compare the work flows of two related systems or countries. This can make possible collaboration, reuse, and the identification of which international standards are appropriate.

!! Discussion
1. Discuss a time when you were asked the same question twice. 
2. Collaborate on mapping a work flow for a health system. Start with something small like a clinic. Show the individuals involved and the data that flows between them.

!! Further Information 
[[Monitoring and Evaluation]]

!! Examples from the Field 

In Malawi at Kamuzu Central Hospital patients arrive very early to ensure that they get the healthcare services they need. Before an electronic patient registration system was created patients would queue for hours every morning, stretching off from the hospital into the parking lot exposed to the sun or rain. Whether or not a patient had been to the hospital before they were required to fill out a paper form. For many this was not a straightforward process, and moving each patient registration window would require a lot of time. Of course, registering patients, and being able to know how many people are coming and for what services is a fundamental requirement for managing a hospital. 
When Baobab Health created an electronic patient registration system it was important to be able to provide the hospital with the information they needed for management purposes. It was also important to not dramatically alter the workflow. As a result, Baobab studied the existing workflow and built a touchscreen based system that enabled clerks with little training to be able to register patients. 

Malawi CD4 lab data transfer for patient management.  
Malawi HIV reporting.  
IHI work in South Africa Joburg General hospital on patient flows.  
Kisumu team meetings on patient flows.  
Eldoret use of patient summaries to provide just in time data for clinical teams.  
CRIS collection on HIV indicators.  
Rwanda Partners in Health work of using patient data for better stock management of pharmaceuticals.
{{{
// Specify your account number here!
_uacct = "UA-1234567-1";

// AutoLinkTiddler as a namespace for tracking related functions
var AutoLinkTiddler = {
  // store a reference to the original displayTiddler function
  displayTiddler: story.displayTiddler
};

AutoLinkTiddler.addLinks = function() {
  /*if (readOnly) {
  urchinTracker.apply(this, arguments);
  }
  */
  /* TODO add action here */
};

AutoLinkTiddler.addLinksAndDisplayTiddler = function(srcElement, titles) {
  // log with the tracker
  AutoLinkTiddler.addLinks('/' + titles);
  // call the original displayTiddler function
  AutoLinkTiddler.displayTiddler.apply(this,arguments);
};

// replace the default displayTiddler function with a tracking version
story.displayTiddler = AutoLinkTiddler.addLinksAndDisplayTiddler;

// Call once for the initial page load
AutoLinkTiddler.addLinks();
}}}
<<forEachTiddler
  where
  '! tiddler.tags.containsAny([["excludeLists"]])'
  write
  '"<<redirect \""+tiddler.title+"\" [["+tiddler.title+"]]$))<<redirect  interoperable [[Interoperability]]$))<<redirect  meetings [[Constructive Meetings]]$))"'
>> 
Mike is a Mike McKay crazy dude that runs

<<redirect crazy temp>>

Interoperability

use it or lose it

interoperable

meetings