*****************************************
Initial Thoughts on OpenHIE
*****************************************

       The salient features are

       [1] "What should be in the SHR ?"

       [2] In what format should data be exchanged ?

       [3] What about scalability ? Can OpenMRS fit the bill ?

       [4] What about HIM-vs-SHR.  Shouldn't the boundary be around
       both of them ?


       Background

       I have worked for 15 years on the Regenstrief/INPC/IHIE
integrated health record for Indiana. (I will call this "INPC" for
shorthand.)  Our architecture is based on a simple database, and heavy
use of HL7 2.x The primary database representation for discrete data is a
straight forward mapping of the OBX segment.  We support discrete
results, text reports, reports with attached images and/or PDF
renderings.

       To be honest, my first impression is that OpenHIE is
"technology enamoured".  And so, as I consider this architecture, I am
asking myself: "Couldn't the very simple Regenstrief architecture
solve their problems?"  And, to be fair, I ask the coverse: "Would the OpenHIE
architecture make my life easier?"


       I want to argue the following
	   
	   
	   [1.a] The SHR should support three shapes of data: 
	       Discrete results OBX
	       Documents OBR + one giant textual OBX
	       Picture Annotations OBR + OBX||TX| + OBX||ED|
	       Clinically annotated Documents OBR + OBX||TX| + OBX||CE|...

	   [1.b] The role of the Ministry of health (MOH) is to
	      mandate that certain elements be collected. (This
	      determines a minimum data set) And that certain clinical
	      real-world treatment protcols be followed.  (This
	      determines more data that must be in the SHR in order to
	      provide care at a clinic.)

	   [2] That HL7 V2.x is a good protocol for exchanging data
	      between clinics and the central SHR.

	   [3] That the problem is inherently horizontally scalable.
	      That is, we could in princple, have 10 SHR's in
	      parallel, and randomly assign patients to SHR's, so that
	      each SHR recieves 1/10th the load.

	   [4] That the OpenHIE needs to be kept simple. We should
	       design for [Exposed Registries -- un-mediated by an ESB],
	       and for [Smart Support for Dumb Edge Nodes -- Ie. a
	       smart HIM that could be an ESB.]
	   

   I'll be sending separate emails on these issues.


 PS. When I say "argue", I mean it in the friendliest, most open way
 possible.  I want to take the position that I favor, then I want you
 to knock it down.  I'll help you! Let's see how it plays out.