[Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP

Justin Richer jricher at mit.edu
Mon Jun 15 21:11:02 UTC 2015


That’s a correct characterization, and these are not formal requirements documents. Since these use case documents will not likely be published as formal documents at all, but instead are meant to guide the development of the standards and profiles, then it’s appropriate to talk about both constraints and requirements within them.

 — Justin

> On Jun 15, 2015, at 4:48 PM, Maxwell, Jeremy (OS/OCPO) <Jeremy.Maxwell at hhs.gov> wrote:
> 
> The need to use FHIR is a technical constraint, not a requirement.  Technical constraints should be captured in a separate section from requirements.  The requirement is that the data flow is “simple” and “seamless” which need to be measurably defined so we know when “simple” and “seamless” have been achieved.
>  
>  
>  
> From: Justin Richer [mailto:jricher at mit.edu] 
> Sent: Monday, June 15, 2015 4:37 PM
> To: Maxwell, Jeremy (OS/OCPO)
> Cc: Sarah Squire; openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP
>  
> I disagree that these use cases need to be technology agnostic. This group is going to be working on FHIR-based APIs, let’s just call it out as that instead of pretending that we’re building to some undefined API.
>  
>  — Justin
>  
> On Jun 15, 2015, at 4:11 PM, Maxwell, Jeremy (OS/OCPO) <Jeremy.Maxwell at hhs.gov <mailto:Jeremy.Maxwell at hhs.gov>> wrote:
>  
> Couple of suggestions:
> 1.      In step 3a, it’s not necessarily mandatory to store the driver’s license and insurance card images in the EHR.  In particular, for the driver’s license, if I was an EHR designer, I’d question why it needs to be stored.  Data minimization is a great security technique—data cannot be breached if it’s not stored.  The license is used to ID proof Alice.  Once she’s been ID proofed and that’s been recorded (step 3b), the license is no longer needed.
> 2.      Remove reference to FHIR in step 4.  Use cases are requirements and they should be technology-agnostic.  If the real requirement is that the “bidirectional information transfer is simple and seamless”, then say this and define what “simple and seamless” mean.
>  
> Thanks,
>  
>  
>  
> From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net <mailto:openid-specs-heart-bounces at lists.openid.net>] On Behalf Of Sarah Squire
> Sent: Monday, June 15, 2015 3:55 PM
> To: openid-specs-heart at lists.openid.net <mailto:openid-specs-heart at lists.openid.net>
> Subject: [Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP
>  
> Hello all,
>  
> I've attached a write-up of the enrollment use case incorporating feedback from the last three calls. Thanks everyone for your valuable input. I think this is much more solid now. Please chime in if there's anything else we can improve upon.
>  
> Sarah
>  
> Sarah Squire
> Engage Identity
> http://engageidentity.com <http://engageidentity.com/>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net <mailto:Openid-specs-heart at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150615/0f23d630/attachment-0001.html>


More information about the Openid-specs-heart mailing list