Ch. 1  What should be in the SHR?

       [[ Three Shapes of Data ]] 

       We seemed to agreed on one conference call that the overall
       record needs to contain three shapes of clinical data 

           [a] Discrete results (clumped by battery)
	   [b] Full Text ascii documents (Human readable, machine parsable)
	   [c] Full Fidelity pretty documents & Images (Human readable
	      PDF renderings, particularly of tables and diagrams.
	      Key frame images and snapshots)
	   [d] .. and the combination of a full text document(#b), 
	       with a supplmental pretty rendering(#c),
	       and also some discrete data (#a) tagged on.

      

      So, one answer to "What should be in the SHR?" is 
	  "What CAN be in the SHR ?"

	      "All three shapes of data."
	      "Any data of this shape that you want."



      [[ "Should" ... according to whom? ]]

       Given that we can hold all three shapes of data, the question
"What should be in the SHR?" seems then to focus on  
	   o. what clinical domains should be covered (Lab, Micro, OB,
	      vaccination...), and
	   o. "How should the data be coded?"


       The most striking aspect of OpenHIE, when compared to INPC, is
that OpenHIE has the opportunity to standardize on terminology, and
INPC has been, historically, a "data beggar" -- we take whatever you
will send.

     To take advantage of the opportunity to prescibe codes, I think 
of the problem as:
   What data *must* people send ?
   What data *should* people send ?
   What data *may* people send ?


   "Required data" consists of data elements that are needed

       [1] Data for public health.  

	   Data which, if collected, would greatly facilitate 
	   macro-level health management.

	   For example, "if every birth collected elements X, Y and Z,
	   then we could understand the role of ABC and DEF in infant
	   mortality."

	   We would then require X Y and Z.
	   

      [2] Data for actual care.
      
	  Data which is needed for direct care.  This can be data
	  which is needed for (and collected by) "well established
	  care protocols."

	  In this line would be things like "Data from the Initial
	  Delivery Assement Form".

	  Thought of narrowly, this would be the measurements and
	  reports that fit into standard care protocols.

	  If county X decides that "TB protocol 5" should include
	  steps 1 2 and 3, which need forms F1, F2 and F3, then,
	  by golly, the data of forms F1,F2, and F3 should be
	  collected by edge nodes, and should be sent in the patient download.


    Data that "should be sent" .... is somewhat vague.  Once you are
already sending data required for global metrics, and for well defined
protocols, what data is left ?

    Presumably, it is data that your particular edge software uses and
displays. It would fall into a copule of categories.

	[Case 1] Most edge systems will want to use this data.  It is part
	of good care, but not part of a formalized protocol (like F1,
	F2 and F3). This data, you "should" send.

	"Should be sent" data is part of "best practices", and "should be
	sent data" constitutes data that clinicians can expect to find
	and that edge systems should feel an obligation to collect.

	[Case 2] It is data that mainly  your particular software uses.
	This "may" be sent, so that the SHR will be able to
	regurgitate it upon the next encounter with the patient.
	If you send peculiar data, other systems way not fully know
	what to do with it, but,  a human readable representation
	should be create(able) for it.

	[Case 3] Once you allow "may", then anything else can be sent.
	I would not prevent a system from sending data that it has.
	If it one of the supported shapes, then the backbone should be
	able to receive it, and then regurgitate it.

	Ideally, it it is sending data it feels is essential to care,
	but that this data is in the "may be sent category", then the
	edge system should take care to ensure that the "human readable format"
	of the data contains the essential information.




      [[ What about Codes? ]]

   Now, I assume that the MOH is in a position to mandate the codes
used in the required data.  It will mandate, for example, that form F1
be used, and that it will use the following set of LOINC codes for the
elements of the form. It should be a simple matter for the MOH to
define the exact codes for the required data, and to say something
like: "Use LOINC for the 'may' be sent data."


      [[ Summary ]]

      So, in the end, I feel closure on "What should be in the SHR?"
if we say:

      	 [1] The SHR machinery can handle all data of the suppored
	    Shapes. Edge nodes can store and retrieve any data they
	    want provided it is in the supported shapes.
	    (So I won't argue with anyone who *want*s to store data.
	    However, they just can't expect other's to collect it, too.)

	    The SHR must be able to return any data of the appropriate
	    shape, in its original shape.
	    (I would want it to be *able* to turn a discrete lab panel into a
	    "lab result text document")
	    

         [2] The MOH will define some required forms and the contained
	    data elements.  Edge systems can count on these be
	    collected and available.

         [3] The MOH will define standard coding for required
	    elements, and mandate the use of stanard coding system for
	    extra elements.