Comments on Life as a Healthcare CIO: The Implementation Workgroup Testimony

It's not about SOAP vs. REST, it's about easy vs. ...

2009-11-03T23:57:20.027-08:00

It's not about SOAP vs. REST, it's about easy vs. hard. Building it yourself is hard (but not too hard). Using the work of others is easy. I have some experiences with both that I've documented here.

Although the desire to keep the standards simple s...

2009-11-02T14:03:50.708-08:00

Although the desire to keep the standards simple seems to be quite well received, simplicity in relation to transmission of data often does not adequately protect the privacy or confidentiality concerns of the individuals to whom the data relates. Building a system that will eventually protect the privacy of individuals means that their confidentiality will not be initially preserved. Essentially, such an approach places the privacy of individuals in jeopardy and increases the public's distrust for electron transmission of sensitive information. Even transmission of prescriptions or lab results exposes the medical condition of the individual to whom that information pertains.

First, thank you for allowing me to participate in...

2009-10-31T11:17:01.735-07:00

First, thank you for allowing me to participate in the panel.

Second, relative to your comment that HIT standards should stay out of the transport space, it occurs to me that the whole of XDS.b could be described in REST as follows:

1) Get a list of known documents: GET to URI *baseuri*/documents/
*patient_id*, where *patient_id* could be an OpenID, or an HL7 triplet
of assigning authority + ID type + ID, returns a list (XOXO?) of
document location URIs, in the format:
*baseuri*/documents/*document_id* (note that if the *baseuri* is a
registry, the documents could be served out of different locations

Query strings can be used to subset the list based on creation time, source, etc.

2) Get a document: GET to document location URI
3) Add a new document: POST the document to /*patient_id*/documents
(POST returns the location of the newly created document)
3a) Add a reference to a new document POST the URI to /*patient_id*/
documents
4) Update an existing document: PUT the document to the document URI

If you want to register or provide multiple documents, do multiple POSTS.

And that is, I believe, the entire XDS.b spec in 4 bullet points.
But, based on REST, we can do so much more:
1) Content negotiation can be used to get documents of different types
(C32 CCD, CCR, non-C32 CCD, CDA text/PDF, simple PDF, text, even movies, photos, etc.)
2) We can use 303s to notify when the authoritative source has moved
3) We can use ETags to version documents and let people know if the document version has changed.

John, excellent summary. I'm concerned, however, ...

2009-10-30T14:52:28.972-07:00

John, excellent summary. I'm concerned, however, about how well the HITSP work products to date correspond to the stated needs of the testifiers. For instance, "simplicity" is the last word that comes to mind in reviewing the HITSP harmonization standards, which consist of dozens of interleaved constructs, capabilities, interoperability specifications, service collaborations, and technical notes with dependencies on numerous other standards and implementation guides from HL7, IHE, NCPDP, etc. Can mere mortals implement specifications like these in a consistent manner, as required for interoperability?

Great summary and a great meeting yesterday. One ...

2009-10-30T14:44:49.000-07:00

Great summary and a great meeting yesterday. One thing that was was not listed was a federated identity standard/process for the REST point to point exchange. As I write my comment, I see that I could of logged in with the standard the Internet uses for federated identity...OpenID.

Best,
Steven

Thanks for another great summary and clear distill...

2009-10-30T07:56:38.598-07:00

Thanks for another great summary and clear distillation of the "gold star" ideas. With a few years experience in the field, I concur with all your points. I hope similar guidance is applied here in Canada as well.

For Laboratory interfaces, we shouldn't wait until...

2009-10-30T07:07:23.614-07:00

For Laboratory interfaces, we shouldn't wait until 2013. The focus should be on lab results, and not orders. If we establish a standard that 95% of all results require a LOINC cross-reference, then we can obtain a very significant improvement in the current situation.

Also, the HL7 laboratory results standard should be required certification criteria.

This combination would make a very big difference very rapidly. Our goal should be to improve this situation for 2011.