Scope limiting on Documents for mHealth

0 views
Skip to first unread message

Boone, Keith W (GE Healthcare)

unread,
Oct 11, 2011, 11:46:00 PM10/11/11
to iti...@googlegroups.com, iti...@googlegroups.com

A couple of discussion items came out of today’s meeting:

 

Karen and a few others suggested changing the name of the profile to something more representative, like Documents for mHealth.  John noted that one of the scoping possibilities is whether the profile needs to address “Cross Enterprise” or intra-enterprise.  Since the organization that an mHealth application works with could be an HIE (which could deal with the cross-enterprise issues prior to the mHealth device), or a single provider, or a large IDN, I think we could scope it to being “intra-enterprise”.  So, I simply dropped the “Cross Enterprise”, but kept Documents in the name.

 

On scoping, these are some thoughts we’ve had on the transactions:

 

Query:  This is simpler than the full XDS Query capability.  I see a necessary few cases, all of which are simplifications of existing queries in the catalog:

1.       Find a document by class, create/service date, and/or type of facility (a restriction on Find Documents)

2.       Finding Folders (e.g., find a patient’s blood pressure / weight results folder) – list folders for a patient, no need to restrict query to a specific type or code, since in this case, we would expect there to be a limited number of folders where the device can easily locate the one it needs.

3.       Given a folder id , get the contents (restriction on Get Folder).  OK, now that you’ve found the blood-pressure results folder, show me results for this week.

4.       Given a document, get all related documents (so that one could look at history of a document and addenda or transforms).

 

I don’t see a need for queries based on submission set, or queries supporting detailed management, or need to delve into homeCommunityId, as it would seem that in the intra-enterprise case, that detail would be transparent to the device.

 

Provide and Register:  Needs to support only a single document, and optionally a pre-existing folder.  Doesn’t need to support registration of multiple documents.  The use case I see for posting a new document is updating patient data with latest results, providing a single signed consent or registration form, or similar cases, where what the user is always working with is only a single document at a time.  On update, we have one use case where “Update this document” might be used, e.g., filing an updated consent form, but not a lot of others.

 

Retrieve Document:  Document retrieval is singular.  We don’t particularly see a need to get a collection of documents in this environment.

 

                Keith

_________________________________
Keith W. Boone
Standards Architect
GE Healthcare

T +1 617.519 2076
M +1 617 640 7007

keith...@ge.com
www.gehealthcare.com


116 Huntington Ave
Boston, MA 02116
USA

GE imagination at work

Reply all
Reply to author
Forward
0 new messages