Health ID Technical Stack Overview

For the convenience in experience, and to enable providers to support the unique request of the Health ID Trust, which is that each user bundle is monetized for all providers, e.g. there is no traceability and enterprise reporting of license count to ID providers.

View Presentation: Health ID Trust slide deck from IIW2008b

This promotes a connectivity tissue between providers, payers, and people, that focuses on the key drivers for each success.

View Script: Person's signs up for the Health ID Trust

This technology model that includes several technology components. A brief description of each.

OpenID. A unique OpenID has been reserved for each of the people represented by each country that supports Health ID Trust. The system assumes a total of all population. It is the logon accepted at each site I use when I want to prefill information about myself. Since there are privacy concerns with ID/Pseudonyms, it is expected that a set of level of obscurity lives between the site and the requester of information and logon. It is this ID that all common reporting will be run for validating base information requests.

OAuth is setup as a way for me to have an secure channel for assertions between me and my providers, and my providers and other partners I may access. It is focused on the mechanics around certificate discovery and validation between endpoints. A relying party arrangement is setup for me between My Portal (if any) and my primary doctor. As well, I am setup with keys to providers that support my health portal, and am creating a relationship with them that allows me to be private and portable in several directions (my portal keeps a snapshot of aggregate keys and monitors apps that it uses, an individual app can be converted between portals).

Discovery is the mechanic that allows me as a consumer to use my data around my health to find services that match my needs. A key part of the Health ID Trust is enabling a key set of attributes and values that support robust and flexible discovery mechanics. It is expected that this will be a hybrid set of tools and functions, tying into existing processes and communication tools such as B2B, tag-clouds, seo, and web sites, as well as be directed to a more robust set of processes that support rich discovery requests by a person to an provider. [The HTSPE specifications for Hospital Emergency Status EDXL is a good example of discovery that will help the user find the right hospital in an emergency]

Representation is a set of tools that allow discovery to be fulfilled by a vendor. This will follow industry standard documents, freeform, and conform vocabularies (ndc, rxNorm) and other specific company vocabularies

Information Cards are used to provide a base set of information for the user, available by exchanging the card. In this stack, information cards are going to be used for several things for a person in their life, and different combinations of the cards will support different sharing scenarios. There will be individual cards (company @ provider) and generic card for all health, that allows base information exchange across all systems. This one is the one intended to be printed.

HIPPA compliance of the receipt of information across the endpoints, and validity of the person as they sign up will require a second form of authorization, this will be grouped with information in the discovery. A set of information cards that contain credentials with signing authority to receive documents will be the goal. The endpoints are extended to real signature, ip address, voice, photo, or in-person in different situations. An all online solution is the goal of this base flows this stack will support for consumers, with appropriate caveats for key out-of-band processes and situations.

CCR - The Continuity of Care Record specification from ANSI is a key piece of current health provider portability. The Health ID Trust supports a base form, as well as mechanics for further delegation of elements, updates to the code, and key vocabulary maps required to manage the integration. HC7, CCD, EDXL and other industry standards are invited to participate.

Data Portability frameworks support the base mechanic and expectations from parties sharing the data. In Health ID Trust, it is a set of agreements and governance for each of the key parties that participate. ID Providers, Portal Providers, Application Providers, Health Providers, Payor Providers, Friends, Family, Doctors. [LINK]

WhiteList will be used to allow each party, for example portal, to define a set of end points for parts of the Open ID and extended fields and documents that are exchanged between parties. At the base level, it says whether an account can be imported into another system and that endpoint being the host location for the profile. Health ID trust is requesting a peering relationship with all these models to support this in the open terrain.

Family ID. A similar concept to OpenID, but for family validation. This is a mechanic that is validated by a marriage license, and is a new entity that binds the individual identities for individuals. It is leveraged and verified for legal and tax records.

FOAF (Friend of a Friend) Used to pull in contacts from applications and sites.

XFN Used to pull in contacts from applications and sites.

Certificates for connecting CCRs between providers, Health ID Trust, and portals is done through issuing certificates that can leveraged through systems like XRDS, ebXML, and other mechanics to share information between providers on behalf of a person.

Proofing for validating information access in paper form and levels of access, will be represented as flags in profile, with contextual processes on how to process based on requirements of system. Base case will include: in-person, photo, signature, voice

Session between providers is a key domain of the portal, which will have the UI controls for managing the experience for the user. Mechanics to authorize data will be done at the ID provider and not require session between consumer and information flow.

ebXML registry can represent HC7, CCD, RxNorm, and other industry vocabularies between parties, starting at the authoritative source and provide a mapping layer. VRM

Passwords

Human detection

Magnetic Stripe

Barcode

Voice Recognition

SSL

PKI

Browser

Flash

Context services

Me Server