Health Data Exchange Test Cases

Skip to end of metadata
Go to start of metadata

Health Data Exchange Test Cases

Following are materials related to the testing of UMA-based health data exchange contributed by Project hData as part of the UMA validation bounty program. The final versions of these materials were submitted as of 13 Dec 2010. Ultimately the UMA WG may turn these contributed materials into UMA "working drafts".

 


Submission letter

Hello,

I am writing on behalf of the hData project with our submission to the UMA validation bounty program. Our submission relates to medical data exchange via hData, and consists of two workflow diagrams outlining the steps involved in registering primary and secondary data providers. To facilitate sharing and editing, we used the websequencediagrams.com to develop the swimlane diagrams.

One of the features of hData is the use of a Discovery and Authorization Service (DAS), which combines functions of an Authorization Manager and a Discovery Service. The DAS plays a central role in how health data providers and consumers find each other and access authorized patient data from other health data providers. To clarify the dual role of the DAS, we have create two adjacent swimlanes in the enclosed diagrams.

The first diagram (http://tinyurl.com/2fc5v8a) covers the process of (a) registering a user with the DAS, and (b) registering the patient’s Primary Care Physician (PCP) with the DAS. The workflow is general enough to allow user authorization of the PCP to occur by a number of alternatives, including by direct interaction by the patient, or by interpreting a pre-configured policy that the user has set up with the DAS. This allows additional flexibility and convenience for the patient.

The second diagram (http://tinyurl.com/2euop2z) brings an Emergency Room (a third party data consumer/provider) into the picture. The process of authorizing the ER is identical to authorizing the PCP, and is therefore omitted from this diagram. The diagram focuses on the interaction of the ER and PCP, allowing the ER to access the medical record of the patient (or authorized parts thereof). We also cover how the ER receives updates to the patient’s medical records, and the possibility of expiry of the authorization token held by the ER.

Also included as an enclosed file are a number of test cases for these scenarios, based on the Gherkin language. Gherkin allows designers and developers to describe behavior in plain text, and through a simple process, translate the text description into executable test cases. Since these test cases are written in readable text, it facilitates developer interactions with those who create the business logic. As we proceed, these test cases will be converted to executable code.

If you have any questions about our submission, please do not hesitate to contact me or Gerald Beuchelt (gbeuchelt -at- mitre.org)

Sincerely,

Mark A. Kramer, PhD
MITRE Corporation E542
mkramer -at- mitre.org
781-271-3296
mobile: 781-367-4239

Gherkin test cases

The test cases are also available for download as a standalone file.

Swimlane diagram: registering a patient and their PCP with a DAS

This diagram can also be viewed with a variety of styles on the websequencediagrams.com site. (If the diagram is not displaying correctly, try reloading the page in the browser.)

participant Patient
participant "Authorization Manager\n(in the hData DAS)" as AM
participant "Discovery Service\n(in the hData DAS)" as DS
participant "Primary Care Physician\n(primary hData system)" as PCP


note over Patient, PCP:
  Step 0: Registration w/ AM
end note

Patient -> AM: Register new account

note over AM: 
  hData DAS must guarantee
  HIPAA, HITECH compliant 
  authentication
end note

AM -> Patient: Confirmation



note over Patient, PCP:
  Step 1: First Contact hData Registration
end note

note over Patient, PCP: 
   Step 1a: Authorize PCP
   Note that more details of this step are discussed in the Kantara UMA protocol itself. 
end note
Patient -> PCP: Provide URL to patient-specific endpoint within AM

PCP -> AM: Register as healthcare provider of Patient

AM -> Patient: Authorize PCP hData System?
note over Patient: 
  Authorization can be done via
different means: 
  (i) Interactively by Patient
  (ii) Using pre-configured policy at DAS
  (iii) Providing signed authZ token
end note

Patient -> AM: Registration permission granted

AM->PCP: Notify authZ granted

note over Patient, PCP: 
  Step 1b: PCP Accesses Discovery Service
end note

PCP -> DS: Request provider list

DS -> PCP: Redirect to Access Manager

PCP -> AM: Request Access token for discovery

AM -> PCP: Grant Access Token (AT)


loop Access Patient-Specific Provider List
    PCP->DS: Seek provider list (AT)
    DS->AM: Validate AT
    note over AM:
       Validation can be either online
       or through signed tokens 
    end note
    AM-> DS: Confirm validation
    DS->PCP: Patient provider list
end

Swimlane diagram: authorizing an ER to access a patient's medical record at their PCP

This diagram can also be viewed with a variety of styles on the websequencediagrams.com site. (If the diagram is not displaying correctly, try reloading the page in the browser.)

participant Patient
participant "Authorization Manager\n(hData DAS)" as AM
participant "Discovery Service\n(hData DAS)" as DS
participant "Primary Care Physician\n(primary hData system)" as PCP
participant "Emergency Room\n(3rd party hData system)" as ER

note over Patient, AM, PCP, ER:
  Step 2: Third party Access
end note


note over Patient, ER: 
  The emergency room hData system and the hData DAS are introduced to eachother as outlined in Step 1 (both 1a and 1b). At the end
of the introduction, the ER system has a list of hData provider systems for the Patient, including the PCP. The ER system selects the PCP
for the following workflow. The scenario begins with the ER requesting data from the PCP.
end note

ER -> PCP: Get Patient data

PCP -> ER: Redirect to AM

ER -> AM: Request access to PCP records
AM --> Patient: Authorize access to hData record

note over Patient: 
  Authorization can be done through 
  different means: 
  (i) Interactively by Patient
  (ii) Via pre-configured policy at DAS
end note

Patient --> AM: Permission granted

AM->ER: Access Token (AT)

ER ->PCP: Get Patient data (AT)

PCP->AM: Validate AT
note over AM:
   Validation can be either online
   or through signed tokens 
end note
AM->PCP: Token OK

PCP -> ER: Return data

ER -> ER: Upddate patient record

opt Poll for patient data at a later time
    ER ->PCP: Poll for new patient data (AT)
    
    PCP -> AM: Valiate AT
    note over AM:
       Validation can be either online
       or through signed tokens 
    end note

    alt Token OK
      AM -> PCP: Token OK
      PCP -> ER: Patient data update feed
    else Token expired
      AM -> PCP: Token expired
      PCP -> ER: Token expired\nredirect to AM
      ER -> AM: Request AT
      AM --> Patient: Authorize access to hData record

      note over Patient:  
  Authorization can be done through 
  different means: 
  (i) Interactively by Patient
  (ii) Via pre-configured policy at DAS
end note

      alt Authorization granted
      Patient --> AM: Provider permission granted

      AM->ER: Access Token (AT)
      ER ->PCP: Poll for new patient data (AT)
    
      PCP -> AM: Valiate AT

    
    note over AM:
       Validation can be either online
       or through signed tokens 
    end note

    AM->PCP: Token OK
    PCP -> ER: Patient data update feed

    else Authorization denied
      Patient --> AM: Provider permission denied
      AM -> ER: Unsuccessful AT response
    end
    end
end
 
Bookmarks

Is this site useful to you? Please share it!

| | More
On This Page:
Pages in this Space:
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.