OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [Fwd: [Fwd: RE: [regrep] RE: DNS like distributed search forRegistryObjects]]


(Sending on behalf of John Hardin)

-------- Original Message --------
Subject: [Fwd: RE: [regrep] RE: DNS like distributed search for
RegistryObjects]
Date: Fri, 14 Apr 2006 12:55:34 -0500
From: John Hardin <john@maphin.net>
Reply-To: john@maphin.net
Organization: maphin.net
To: regrep@lists.oasis-open.org

Dear Reg/Rep folks -
I have started a thread in the ebxmlrr-tech mailing list that Farrukh
has requested I cross post to the regrep mailing list. Specifically,
here are my concerns (top email in the thread). You can see responses to
this initial posting after.

**********************
Farrukh and all on the ebXMLrr list -

As most of you are aware, the healthcare industry is moving rapidly
towards implementation of a national health information network. All
indications point to organic growth, with small regional or affinity
based domains springing up across the country, where electronic health
records information will be stored for individuals. The best models
(particularly from HIMSS and the Integrating the Healthcare Enterprise
groups) are building the core framework with ebXML reg/rep at the heart
of the storage mechanism.

The need to locate complete records for persons who reside in multiple
places, or who have moved, vacation, etc. is a real use case, and the
condition will result in storage of an individuals' information in
multiple domains. This will create the need for federation across the
entire ecosystem of domains, in realtime.

Models for federated patient identity based record locator services are
being floated. This looks to me like the DNS hierarchy, where there will
be a patient locator query broadcast across the entire trusted ecosystem
of registries.

I am curious about the OASIS or ebXMLrr communities' experience in this
sort of large scale test, pilots or proofs of concept. Has there been
any work that we can reference to understand the characteristics of mass
traffic across an ecosystem of dozens or hundreds of federated registries?

Any ideas about performance or gotchas in implementing this type of
infrastructure would be very helpful.

Thank you...


-- 

|  john c hardin
|  Chief Technology Officer
|  http://www.maphin.net
|  606.598.7353 office
|  606.813.4316 cell
|  mailto:john@maphin.net



*** Responses ***


-------- Original Message --------
Subject: 	RE: [regrep] RE: DNS like distributed search for RegistryObjects
Date: 	Fri, 14 Apr 2006 07:42:49 -0500
From: 	Moehrke, John (GE Healthcare) <John.Moehrke@med.ge.com>
To: 	David RR Webber (XML) <david@drrw.info>, Matt MacKenzie
<mattm@adobe.com>
CC: 	<john@maphin.net>, "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>,
<regrep@lists.oasis-open.org>



David,

The concern you have is healthy, and I can assure you that the efforts
are all linked. The IHE would rather see standards developed within
standards organizations. I am confident that is the reason John passed
this use-case along to regrep. John Hardin is involved in the IHE
efforts as well. The IHE is also dealing with the laundry list of
patient matching, privacy and security issues you raise. Again, we are
passing some of our needs off to organizations like SAML and XACML. We
are pushing our own standards organizations (HL7, DICOM, ASTM) to fill
some gaps. Third, the IHE does clearly describe the residual risks that
need to be solved in Policy, Procedure and Magic. So please don't push
this request aside as not being thought through (challenge us to prove
it, yes). We (IHE) can encourage standards to fill gaps that we identify
within the healthcare market, but clearly we can't force the problem to
be solved.

Right now we are in the process of writing a white paper on the subject
of connecting multiple Registries. The reality is that Registries will
be the master over a region, that region today is small based on past
administrative influences (healthcare company owned, state government
run, NHIN contracts). This is the architecture that you referred to as
IHE/XDS. The problem is that people are not very sedentary, they like to
go on vacations and change jobs. Thus we perceive needs in the future to
find historical information across all. Thus why we bring this need up.
The issues this raises have not been lost on us: privacy, policy,
contractual, safety, etc.

John Moehrke
GE Healthcare


------------------------------------------------------------------------
     *From:* David RR Webber (XML) [mailto:david@drrw.info]
     *Sent:* Thursday, April 13, 2006 8:32 AM
     *To:* Matt MacKenzie
     *Cc:* john@maphin.net; Farrukh Najmi; regrep@lists.oasis-open.org
     *Subject:* RE: [regrep] RE: DNS like distributed search for
     RegistryObjects

     Farrukh,

     I'm concerned here as part of what John is asking for is NOT a
     technology solution.

     Fire, Aim, Point - I suspect we need a little more Point, Aim, Fire
     - and BCM directed analysis first... as to the business needs and
     actual service models.

     The models John is indirectly referencing are basically competing
     proprietary approaches to this from service providers - there are
     literally dozens of these competing for market share.
     http://www.ehto.org/ehto/ehealthrecord.html

     Paradoxically none of them seem to have the slightest idea (the ones
     of asked!) about the notion of shared registry services - basically
     they are "eyes down" - their answer is "Yes - we can do that - just
     buy our service / install our software".  The notion of supporting
     an open public API specification is something they do not have time
     to waste chasing...because their system has all the information you
     ever need.

     Now - there is however the IHE/XDS work.  For me this has always
     been the mostly likely candidate - because the biggest issue here is
     NOT technology - its policy and security and access models.

     Who is allowed to see what?  How do you credential the search
     query?  You certainly cannot just hand out patient information
     willy-nilly.  The best I think you can hope for is to ascertain that
     a registry MAY have information that relates to a patient.  Notice -
     data entry screw-ups happen frequently in busy hospital and care
     center environments - so matching on Patient Name, Telephone #, Age,
     Address, SSN with some weighting algorithm may be needed ( I wrote
     one of these for 3M Healthcare some 10 years ago now to reconcile
     patient records across city care providers - such as Cincinnatti,
     Baltimore, Pittsburg and so on where you have same patient going to
     one or more providers in the same city care group).  Notice even the
     SAME hospital may have duplicate records for the one patient!

     Given all these caveats - here's a short list of business factors:

     1) Security model is essential - who is making query, what
     information is to be matched, what can be returned?

     2) Audit trail is essential - who accessed the information and when?

     3) What certificates and authentication can be applied?  To the
     patient themselves, and to the requester?

     4) Who owns the information?  The patient or the care provider?

     5) What API needs to be defined to support the business requirements?

     6) How do care providers begin to participate in this?

     I suspect the answers to much of this lay in a joint collaboration
     with IHE/XDS, NIST, OHC Project and this TC - to hammer out
     extensions to the existing IHE/XDS secure server - because that way
     - whatever is built then becomes immediately accessible to all those
     currently implementing those servers...

     See:

http://ebxmlforum.blogspot.com/2006/04/open-healthcare-framework-ohf-project.html

     Thanks, DW


         -------- Original Message --------
         Subject: [regrep] RE: DNS like distributed search for
         RegistryObjects
         From: "Matt MacKenzie" <mattm@adobe.com>
         Date: Thu, April 13, 2006 8:45 am
         To: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>,
         <regrep@lists.oasis-open.org>
         Cc: <john@maphin.net>

         It is possible to represent a classification scheme using
         DNS-SD...which I
         think is a great idea as it would allow for very fine grained
         partitioning.
         Please let me know how I can help, I'll try my best to find some
         time.
         -matt

         -----Original Message-----
         From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
         Sent: Thursday, April 13, 2006 8:14 AM
         To: regrep@lists.oasis-open.org
         Cc: john@maphin.net; Matt MacKenzie
         Subject: DNS like distributed search for RegistryObjects


         Dear Colleagues,

         Attached is an email from John Hardin whom many of you may know
         already.

         John's email has reminded me of the the need for the TC to
         define a DNS
         like distributed search for RegistryObjects.
         He shares a very real use case from Electronic Patient Records
         world on
         how important this functionality is.

         I share this sense of importance and would like to propose that
         we as a
         TC consider starting a work item focused on
         defining a normative spec addressing this requirement. As a
         starring
         point we could study past work by Matt MacKenzie on the subject:


http://www.oasis-open.org/committees/download.php/6852/tn-ebreg-dnssd-02.htm
         l


         What do Matt and TC colleagues think?

         --
         Regards,
         Farrukh

     ---------------------------------------------------------------------
     To unsubscribe from this mail list, you must leave the OASIS TC that
     generates this mail. You may a link to this group and all your TCs
     in OASIS at:
     https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-- 

|  john c hardin
|  Chief Technology Officer
|  http://www.maphin.net
|  606.598.7353 office
|  606.813.4316 cell
|  mailto:john@maphin.net



-- 

|  john c hardin
|  Chief Technology Officer
|  http://www.maphin.net
|  606.598.7353 office
|  606.813.4316 cell
|  mailto:john@maphin.net

begin:vcard
fn:Farrukh Najmi
n:Najmi;Farrukh
email;internet:farrukh.najmi@sun.com
tel;work:781-442-9017
url:http://ebxmlrr.sourceforge.net/tmp/DSCN0278.JPG
version:2.1
end:vcard



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]