際際滷

際際滷Share a Scribd company logo
NetWork 3 - HealthVault at work
HealthVault u praksi
Catalin Gheorghiu
I Computer Solutions
NetWork 3 - HealthVault at work
NetWork 3 - HealthVault at work
Agenda
 Sta je problem?
 Sta je HealthVault?
 Velika slika (bas velika slika)
 Kako to izgleda (vas Health Vault racun)
 Nekoliko vazni koncepti(samo nekoliko)
 Kako se programira
 Rasprava o nekim mogucim namjena (Q & A)
Sta je problem?
Sta je HealthVault?
HealthVault je kljuc
Neutralan, pacijent kontrolirano resurs koji omogucuje dugorocnu obiteljski
angazman
Velika slika (bas velika slika)
Kako izgleda vas HealthVault account
Nekoliko vaznih koncepta
(samo nekoliko)
 Pre Production Environment PPE
 Custodian
 Rights fine graining
Mobile aplikacije su vise i vise
 WP7, iOS iAndroid
Kako se programira
SODA
(Software on device authentication)
Following is a typical connection workflow for a HealthVault mobile application:
1. User launches application for the first time.
2. Application obtains a new application identifier, shared secret, and app creation token by calling
the HealthVault web service and passing in the master application identifier,
3. Application directs user to HealthVault Shell for authentication and authorization, passing along
the app creation token.
4. The user signs in to HealthVault Shell and grants the application access to the user's records.
5. The HealthVault Shell redirects the user back to the application, indicating success or failure.
6. Application stores the new application identifier and shared secret.
7. Application calls the HealthVault web service to create an authenticated session token using the
application identifier and shared secret to identify the application.
8. Use the CreateAuthenticatedSessionToken request to create a session token. For more
information..
9. At this point, your application can operate like any other offline application. For example use
GetAuthorizedPeople to obtain a list of users and records authorized with this instance of the
application.
Patient connect
A typical Patient Connect connection is made in the following way.
1. A patient visits a clinic and wants to enable the clinic to exchange data with his HealthVault
account.
2. The clinic's app creates a connect request in HealthVault based on the patients ID in the clinics
system, a friendly name for the patient, and a secret question and answer that will be used to
verify the patients identity.
3. HealthVault returns an identity code for the connect request.
4. The app then sends the user an email containing the identity code and a link to HealthVault.
The email does not include the secret question or answer. (Alternatively, the clinic could give the
patient a print-out with the information.)
5. Later, the patient goes to the URL provided by the clinic and enters the identity code.
6. The patient is prompted for the answer to his secret question, and when he enters it correctly,
this validates his identity.
7. The patient selects the HealthVault record to use with the app and then authorizes it.
8. The user receives confirmation that the app has been authorized. This includes the Patient
Connect Success message that you configured in the Application Configuration Center .
9. The app is now authorized to exchange data with the users record, but it doesnt know it yet. It
finds out by periodically polling HealthVault for the list of connect requests that have been
authorized since the last time it checked. In doing so, it retrieves the HealthVault IDs for the
users and their records.
10. The app discovers that the user has authorized the app, so it stores the HealthVault IDs for the
user and record and begins exchanging data with the record.
drop-off and pick-up
(DOPU)
A typical DOPU connection is made in the following way:
1. A patient visits a lab and wants to store her lab results in her HealthVault account.
2. The lab's application creates a DOPU package in HealthVault containing the patient's results, the
patient's ID in the lab's system, a friendly name for the patient, and a secret question. The secret
answer is used to encrypt the DOPU package and to later verify the identity of the user.
3. HealthVault returns an identity code for the DOPU package.
4. The application then sends the user an email containing the identity code and a link to
HealthVault. (Alternatively, the lab could give the patient a print-out with the information.)
5. Later, the patient goes to the URL provided by the lab and enters the identity code. She will also
create an account if she doesn't already have one.
6. The patient is prompted for the answer to her secret question, and when she enters it correctly,
this validates her identity.
7. The patient then selects the HealthVault record in which the lab results should be stored.
8. The data from the DOPU package is written to the patient's record.
9. The patient receives confirmation, which includes the Patient Connect Success message that
was configured in the Application Configuration Center
Demos
NetWork 3 - HealthVault at work
Hvala!
Contact:
My Blog http://ronua.ro/CS/blogs/catalin/default.aspx
My Email catalin.gheorghiu@ronua.ro
NetWork 3 - HealthVault at work

More Related Content

NetWork 3 - HealthVault at work

  • 2. HealthVault u praksi Catalin Gheorghiu I Computer Solutions
  • 5. Agenda Sta je problem? Sta je HealthVault? Velika slika (bas velika slika) Kako to izgleda (vas Health Vault racun) Nekoliko vazni koncepti(samo nekoliko) Kako se programira Rasprava o nekim mogucim namjena (Q & A)
  • 8. HealthVault je kljuc Neutralan, pacijent kontrolirano resurs koji omogucuje dugorocnu obiteljski angazman
  • 9. Velika slika (bas velika slika)
  • 10. Kako izgleda vas HealthVault account
  • 11. Nekoliko vaznih koncepta (samo nekoliko) Pre Production Environment PPE Custodian Rights fine graining
  • 12. Mobile aplikacije su vise i vise WP7, iOS iAndroid
  • 14. SODA (Software on device authentication) Following is a typical connection workflow for a HealthVault mobile application: 1. User launches application for the first time. 2. Application obtains a new application identifier, shared secret, and app creation token by calling the HealthVault web service and passing in the master application identifier, 3. Application directs user to HealthVault Shell for authentication and authorization, passing along the app creation token. 4. The user signs in to HealthVault Shell and grants the application access to the user's records. 5. The HealthVault Shell redirects the user back to the application, indicating success or failure. 6. Application stores the new application identifier and shared secret. 7. Application calls the HealthVault web service to create an authenticated session token using the application identifier and shared secret to identify the application. 8. Use the CreateAuthenticatedSessionToken request to create a session token. For more information.. 9. At this point, your application can operate like any other offline application. For example use GetAuthorizedPeople to obtain a list of users and records authorized with this instance of the application.
  • 15. Patient connect A typical Patient Connect connection is made in the following way. 1. A patient visits a clinic and wants to enable the clinic to exchange data with his HealthVault account. 2. The clinic's app creates a connect request in HealthVault based on the patients ID in the clinics system, a friendly name for the patient, and a secret question and answer that will be used to verify the patients identity. 3. HealthVault returns an identity code for the connect request. 4. The app then sends the user an email containing the identity code and a link to HealthVault. The email does not include the secret question or answer. (Alternatively, the clinic could give the patient a print-out with the information.) 5. Later, the patient goes to the URL provided by the clinic and enters the identity code. 6. The patient is prompted for the answer to his secret question, and when he enters it correctly, this validates his identity. 7. The patient selects the HealthVault record to use with the app and then authorizes it. 8. The user receives confirmation that the app has been authorized. This includes the Patient Connect Success message that you configured in the Application Configuration Center . 9. The app is now authorized to exchange data with the users record, but it doesnt know it yet. It finds out by periodically polling HealthVault for the list of connect requests that have been authorized since the last time it checked. In doing so, it retrieves the HealthVault IDs for the users and their records. 10. The app discovers that the user has authorized the app, so it stores the HealthVault IDs for the user and record and begins exchanging data with the record.
  • 16. drop-off and pick-up (DOPU) A typical DOPU connection is made in the following way: 1. A patient visits a lab and wants to store her lab results in her HealthVault account. 2. The lab's application creates a DOPU package in HealthVault containing the patient's results, the patient's ID in the lab's system, a friendly name for the patient, and a secret question. The secret answer is used to encrypt the DOPU package and to later verify the identity of the user. 3. HealthVault returns an identity code for the DOPU package. 4. The application then sends the user an email containing the identity code and a link to HealthVault. (Alternatively, the lab could give the patient a print-out with the information.) 5. Later, the patient goes to the URL provided by the lab and enters the identity code. She will also create an account if she doesn't already have one. 6. The patient is prompted for the answer to her secret question, and when she enters it correctly, this validates her identity. 7. The patient then selects the HealthVault record in which the lab results should be stored. 8. The data from the DOPU package is written to the patient's record. 9. The patient receives confirmation, which includes the Patient Connect Success message that was configured in the Application Configuration Center
  • 17. Demos