DNS+and+Microdata+Overview

=Introduction=

This section of the wiki will explore the DNS + Microdata recommendation offered by the Privacy and Security Workgroup of the Health IT Standards Committee (HITSC) and provide an overview of the concept of DNS and Microdata.The intent of this page is purely informational and provides background to the workgroup as data element mapping begins to the microdata vocabularies that are currently available at http://schema.org.

The recommendation from the HITSC specifically reads as follows:


 * Recommend that S&I Framework team consider approach of structuring and encoding web content, using standard schema and vocabulary, for meeting need for nationwide access to directory information without requiring “national provider directory”.** Further instruction was provided on this recommendation by the HITSC:
 * 1) Organizations create public web pages containing directory information they wish to expose for search
 * 2) Provider directory information is structured and encoded into the web page, using standard schema and vocabulary
 * Improves search engine indexing
 * Enables extraction of information into local systems (EHR, Exchange gateway, Direct HISP, etc.)
 * 1) Organizations can obtain Extended Validation certificates to provide assurance of the authenticity of its web pages
 * Standard search engines provide a flexible and free Query Service
 * 1) DNS is used to retrieve digital certificates for the published service address names which have been embedded in the web pages

The S&I Framework has been given direction by the HITSC to consider the microdata option versus microformats, for several reasons: =What is Microdata?=
 * Microformats is generally considered by the browser community to be a "hack" of HTML 4 and is not specifically supported as a "standard." Microdata is part of the HTML 5 standard.
 * Because Microformats rely only on the class and rel attributes, writing parsers to read them is complicated.
 * DNS lacks the attribute-level query options that would be needed to make DNS a true "provider directory" standard and thus, some form of a data model must be paired with DNS. Microdata would be used as the "data model" for DNS.
 * DNS was considered in the Direct Rules of the Road Consensus Statement and would provide continuity for the Direct Project participants.
 * Microdata will most likely be a more "future-proof" option than microformats, which were designed as a way to work around the limitations of HTML 4.

Microdata annotates the DOM of a browser page with scoped name/value pairs from custom vocabularies. To represent a provider's information on a web page (as proposed by the HITSC), all that would be needed is to either reuse an existing vocabulary (many existing vocabularies exists at [|http://schema.org] or define a custom vocabulary to support provider directory requirements. Anyone can define a microdata vocabulary and start embedding custom properties in their own web pages. It is also possible in this way to use more than one microdata vocabulary on the same page, or to nest microdata vocabularies within other vocabularies, all by re-using the natural structure of the Microdata DOM API.

Microdata References and Sources
The following references can be used in helping to understand DNS/Microdata and were used as part of the development of this wiki page:
 * HTML 5: Up and Running - by Mark Pilgrim
 * [|Dive into HTML 5 - by Mark Pilgrim. The Extensibility chapter of the book] was used to capture some of the information listed below and is cited where appropriate.
 * [|W3C HTML Microdata Working Draft - May 25, 2011]
 * Medical Organization vocabulary ([])
 * Physician vocabulary ([]).


 * It is imperative that workgroup members educate themselves as much as possible to contribute to the discussions on data element mappings and possible future usage of microdata.**

Microdata Vocabularies
The data model proposed within the S&I Framework Provider Directory initiative is developed from Section 12 of the Query for Electronic Service Information Use Case. Based on an initial mapping to the data elements from Section 12 of the Query for Electronic Service Information, no current microdata defined vocabulary could meet all the needs of the data elements defined in this data model. A key step for the participants in the workgroup will be to help define possible data element mapping options to use, and if there may be a need to develop new schemas to support these data elements. Microdata allows a way of extending web pages by adding custom vocabularies to the page and thus provides a possible option for national-level provider queries. In this way, a "provider directory" vocabulary could be created that allows provider directory pages to be scrubbed by search engines and makes provider directory queries ubiquitous over the web.

Microdata Implementation Considerations
Microdata has several implementation considerations which will require further study (**but are outside the scope of initial data element mapping**)
 * It is part of the [|HTML 5 Specification,] which is still in working draft. Google, Microsoft, and Yahoo do at this time provide support for HTML 5 and Microdata.
 * Microdata is not designed to be a standalone data format and would need to be embedded into an HTML 5 web page. (//**Pilgrim, Dive Into HTML 5)**//
 * Microdata is great for fine-tuning the semantics of data that’s already in the DOM. (**//Pilgrim, Dive Into HTML 5//**)
 * Depending on how the provider directory pages are constructed, they could be open and transparent to the public or hosted behind an authentication scheme, such as a hospital's intranet.
 * No web browser currently supports Microdata (this requires further testing updates as Opera 12 now supports Microdata and browser support is expected to increase).
 * The S&I Framework is limited in what they can request as changes to the underlying standard since it is part of a broader specification with specific uses outside of healthcare. As such, a recommendation of microdata would mean that new standard is used "as-is" and there may be limited opportunities for changing the standard should healthcare business, technical, or policy requirements dictate it. For example, state and local regulations and policies may restrict or expand the specific use of microdata name/value pairs.
 * The use of a standard search engine is much too flexible and likely will return a lot of useless information that will require analysis or will be discarded. This also allows for no clear method for authenticating the requestor or ability to manage content which may be mixed in terms of public vs. protected attributes. The HITSC proposes that new browser services might be needed to support provider directory queries.
 * A vocabulary would not take into account the fact that there is need for both human intervention and automation to disambiguate identities of providers, especially those that work in multiple locations and for multiple entities. This appears to be a manageable issue but will require further analysis.

As part of the HITSC recommendation, the Privacy and Security Workgroup recommends that organizations get an Enterprise Validation Level certificate as an additional safeguard to ensure organizations can be identified properly. EVL SSL guidelines also specify what specific entities can actually get an EVL SSL. The EVL guidelines have been recently revised to relax these guidelines and these guidelines can be found here - EVL 1.0 Guidelines. =Next Steps=

The next steps proposed below outline possible next steps for the workgroup to consider as work begins to map the data elements from the Query for Electronic Service Information Use Case to existing and potential microdata schemas.

**Create a test Microdata Vocabulary for Provider Directory**
The S&I Framework Provider Directory initiative would help create a Microdata vocabulary to be reviewed and tested, and that is specific to the data elements outlined within the S&I Framework for provider directories. This will reuse existing schemas and define new name/value pairs to be considered.

**Create Example Provider Directory Pages showing proper HTML 5 format**
Based on the microdata vocabulary developed by the S&I Framework, example provider directory pages would also be created by the S&I Framework. These example provider directories in HTML 5 would be used to test the microdata vocabulary developed for provider directories.

**Identify DNS+Microdata Pilots**
The S&I Framework will scan for potential pilot participants from the healthcare community to pilot the use of DNS+Microdata and the example vocabulary that is created. For information regarding Microdata Pilots and guidelines for becoming a Pilot Project, please view the PD Demos and Pilots wiki page.

Determine who would "own" a potential Provider Directory Microdata vocabulary
There will be a need to determine who might own the microdata vocabulary that gets defined by the Provider Directory initiative. Similar to ONC definition of LOINC-specific codesets as part of an NPRM, these microdata vocabularies would have to be version-controlled by some entity. The alternative approach is to release a base vocabulary to schema.org and then allow that vocabulary to be extended by healthcare organizations and providers nationwide as they see fit.