locked
"Offline" Authentication and the Mobile Clinician RRS feed

  • Question

  •  

    I have read several posts on the confusion surrounding offline mode and I am asking MS to clear this up by proposing a solution to my scenario.

     

    First, I have the SDK, and I really want to just dig in and try to see if it meets my needs straight away. I am a very experienced .NET developer.

     

    My company will serve the mobile clinician using a Windows Forms application on a tablet PC. It is a hard, non-wavering requirement that we do NOT use any type of browser-based application. This is because our definition of the way private practice physicians work is the following:

    1. Office personell schedule physician's rounds to patients in hospital before the rounds occur. This visit information is stored on some server OTHER than HealthVault.
    2. The tablet wakes up whenever a visit is scheduled and downloads information from HealthVault to the tablet, maybe in isolated storage for security.
    3. The physician, armed with the patient reference data, makes his patient rounds at the hospital, perhaps collecting more data and sending it UP to HealthVault as necessary.
    4. Patient records may be deleted on the tablet as rounds are completed for each patient, as appropriate.

    One FUNDAMENTAL precept in this workflow is that AT NO TIME must the tablet be REQUIRED to be "online" in the HealthVault application definition of the word. We cannot guarantee that the carrier's WWAN will be able to make a connection in the hospital, or for that matter, anywhere. So data is cached and store and forwarded to/from the tablet at opportunistic times (ASAP, basically).

     

    How would HealthVault assist me as a data store? Please describe EXACTLY the API calls I need to make, and the interaction with respect to authorization that the patient must have with Healthvault to give his physiican basically free access at any time. I think I need to operate in offline mode, with the patient authorizing that mode, and procure a one-time Windows Live ticket. Is that true?

     

    Friday, December 7, 2007 11:14 PM

Answers

  • After the customer has authorized the app to offline access, the app has sufficient information to perform offline access. The authentication for the customer is done through Live ID, but the offline authorization uses a slightly different mechanism.

     

    Architecturally, there would be the client app. It would talk to the web server over a secured channel - something like https. The web server would then talk to HealthVault in offline mode, using the information that it recorded when the customer was using the online application.

     

    If a customer wants to authorize an application to access HealthVault data in offline mode, they can do so. Presumably, a physician would send the customer a link to the application and request that they go there and register.

     

    Custodial access is not related to offline access. I think that it is in most relevant where one customer has power of attorney over another customer, or one customer is managing health care for the other members of their family.

     

    Wednesday, December 12, 2007 7:33 PM

All replies

  • It's not clear to me what information your application would store in HealthVault, but I think I can answer your questions...

     

    The scenario you are describing would require offline access. I'd start by reading this post that explains how to think about offline access.

     

    Offline access works as follows:

     

    1. The user uses a browser to navigate to a web application which has offline access as one of its authorizations.
    2. The user authorizes that application for offline access
    3. The application records the users user-id and the record-id(s) that will be used to access the records.

    At that point, a web application can access that user's information without having the user authenticate into healthvault.

     

    IIRC, the user ID is PersonInfo.Id, and the record id is PersonInfo.SelectedRecord.Id (if all you care about is the current record - if you need to access other records that the user is authorized to see, you would need to store their ids as well)

     

    The code that you use to create an offline connection is here.

     

    A few additional notes:

    1. Data access requests by an application need to pass a reasonableness test before we grant them, as does offline access. As noted in the post I referenced at the beginning of this answer, our goal is for applications to have the absolute minimum amount of data access as they need to implement their scenario.
    2. To prevent partners from building an application on offline access without understanding all the ramifications, none of the sample application ids in the SDK support offline access. If you wish to build an application that uses offline access, you will need to request an application id that includes offline access.

     

     

     

    Monday, December 10, 2007 8:57 PM
  • I'm getting confused by the general term "user". Can you distinguish between "user" as patient, and "user" as physician? The patient authorizes access to a reader of his data right?

     

    How is the general public going to understand the difference between "offline" and "online"? Why can't it be as simple as a patient, I give my physician authorization to consume whatever records I have?

     

    I have already told you that we are NOT using a "web application". We are using a "smart client" which another side of your company seems to understand aand characterize quite well in the medical arena (see below).

     

    I don't want to have the physician as an "Authorized user" of access to his patients records to be required to use a browser application. HealthVault does not seem to give me that option as a purveyor of software to my physician community.

     

    --------

    “The need for clinical workstations is about to increase dramatically as RHIOs take hold over the next three to five years.  Today's RHIOs are focusing on the centralized access to different data sources for the same patient.  Ultimately, this data will need to be served up in an acceptable way to every clinician and this is going to require a new approach to clinical workstations that can easily access all the RHIO data though common record locator services.  Some people are already referring to this as the "last mile" of the RHIO.  I predict that the world of clinical workstations will change over the next few years.  We are going to need a clinical workstation somewhere between the thick client and the thin client clinical workstations of today.  We will need something more akin to the concept of a "smart client" clinical workstation.  This station should come preloaded with many of the common clinical components that clinical applications need to use.  Good examples of these common healthcare components are access to the RHIO record locator service, ability to share context and common clinical authentication.  They could also provide components that support best UI practices like where to locate key information on the screen and UI components that make the views between applications consistent.  One thing that the smart client clinical workstation can do is combine local computer processing and networked processing in an intelligent way to improve response times.  That is what gets me thinking about clinical workstations when I drive my new hybrid car.  Perhaps the way to think of the clinical workstation of the future is as the Hybrid Clinical Workstation.  I look forward to your comments on this and other topics.”

    Clifford Goldsmith, M.D., US Director, Provider Industry, Microsoft Healthcare and Life Sciences

    http://blogs.msdn.com/healthblog/archive/2006/01/03/508761.aspx

     

     

    Microsoft’s own statement of one of the “features” of Smart Client is as follows:

     

    They support work offline – smart clients can work with data even when they are not connected to the Internet (which distinguishes them from browser-based applications, which do not work when the device is not connected to the Internet);

     

    I wish that one side of Microsoft (clinical) would be speaking to the other side (technical) on these issues and forming a consistent approach.

     

    Tuesday, December 11, 2007 12:49 AM
  • I am sorry for being imprecise.

     

    In HealthVault, the data is always owned by the consumer, so it's the consumer (or, sometimes, somebody who is a custodian of the consumer) who does all the authorizing. We wouldn't use the term "patient" because that implies a medical interaction, and there are scenarios (fitness / wellness) where there isn't such a relationship.

     

    The distinction between online and offline is important because of how it relates to the use of the data. When a consumer authorizes access for an online application, they are authorizing access to a specific subset of a record while they are using that application, but only while they are using the application. The application has no ability to look into that record in the future. We believe that there are many cases where this is exactly the kind of data sharing that the consumer wants - sharing that is as limited as possible.

     

    There are other scenarios where offlline access is necessary. Both the underlying platform and the pages where the consumer grants access support both options.

     

    You are correct that this makes the model more complex, but we believe it is in the best interest of the consumer to do so.

     

    WRT clients, we currently do not support clients connecting directly to HealthVault, for reasons explained here.  Since offline access is limited to web applications, scenarios such as the one you are described need to be implemented through some sort of proxy web access - the web application retrieves the information from HealthVault and then passes it through to the main system.

     

    There are several models here. Some systems store data in HV, some do copy in or copy out, and some do synchronization. Regardless of which model is used, getting everything correct is not a trivial development exercise.

     

    I hope that makes things clearer...

    Tuesday, December 11, 2007 1:16 AM
  • Can the "proxy web access " be a web service? Are we just talking about the proxy following an HTTP protocol to get the Windows Live ID, then a ticket, then call the API's to get the records that have been permissioned for an application?

     

    I think a concrete example of what I need would be great, step by step, starting with the "consumer" (not to be confused with a "consumer of data", I see) actions, then the API calls of the proxy to retrieve a permissioned record.

     

    I have to say if I am a consumer, what then is my physician called, who might need access to my data if I am incapacitated, and my "curator" is not around. Can my curator be my physician? I must say I would rather have my physicians have access any time for emergency reasons. As people get older they need not have to worry about this.

     

    Take my Dad. He is almost 80, but built his own web site that houses his and his wife's medical data. He gave each of his physicians a username and password (and me). At any time, his docs can call up his data (he changes it himself), so I don't need to be there to unlock it. How would HealthVault work in his situation?

    Wednesday, December 12, 2007 2:47 AM
  • After the customer has authorized the app to offline access, the app has sufficient information to perform offline access. The authentication for the customer is done through Live ID, but the offline authorization uses a slightly different mechanism.

     

    Architecturally, there would be the client app. It would talk to the web server over a secured channel - something like https. The web server would then talk to HealthVault in offline mode, using the information that it recorded when the customer was using the online application.

     

    If a customer wants to authorize an application to access HealthVault data in offline mode, they can do so. Presumably, a physician would send the customer a link to the application and request that they go there and register.

     

    Custodial access is not related to offline access. I think that it is in most relevant where one customer has power of attorney over another customer, or one customer is managing health care for the other members of their family.

     

    Wednesday, December 12, 2007 7:33 PM