T6

6 Implementation View

This section describes how the relevant components of the RLS logical architecture are implemented. While the logical and process views provide more conceptual models of RLS, the implementation and deployment views relate more to the physical artifacts that make up the RLS-based interoperability framework. The implementation view presents a more detailed view of the organization of the static software elements of the RLS prototype than was presented in the logical view.

Note that implementation of systems based on the RLS architecture is to be undertaken by individual RHIOs, which have significant latitude of action. Each RHIO may choose implementation strategies based on their internal development methods and platform preferences. This section provides only generic implementation related information, and refers to the RLS prototype implementation architecture and platform for purely illustrative purposes.

RLS architecture is generic and platform agnostic, with interoperability based on open connectivity standards such as Web services, and semantic data standards such as the HL7 Reference Information Model. This section also outlines the relevant standards prescribed for an RLS implementation. Given that interoperability is critically dependent on the communication and data standards adopted, the expectation is that each implementation adheres closely to the recommended standards and specifications. More detailed guidance on implementing message format standards and specifications is provided in a separate document: RLS Messaging Communication Implementation Guide.

6.1 Overview

RLS is a classic n-tiered database application with a web-browser based user interface, and capability to interoperate with remote systems using open standard messaging over the Internet. The key interoperability function is realized through implementing a gateway service at each node in the network that provides essential presentation, business and data services and the ability to communicate with other gateways using web services and domain specific data standards. The RLS application may be viewed as comprising two large grained components (or service compositions).

• Patient Index service maintains and enables access to the community Master Patient Index (CMPI) and maintains a community directory / registry for the various clinical data sources, data and message standards, etc.
• CDX Gateways provides a ‘web-service’ wrapper and other utility services to support message based interoperation for the RLS as well as for each clinical data source in the network.

The patient index service architecture essentially comprises components that provide Patient Record Linking / Matching and Patient Record Search services. The CMPI database contains basic patient demographic information and patient identifiers as maintained in the various clinical data sources that publish into the CMPI. Each patient record is tagged with the network resolvable address of its source.

The unified patient view is achieved through linking / matching of patient records based on demographic attributes. Record matching may use deterministic (exact) matching of patient demographic attributes or a probabilistic algorithm which takes into account the variations in source data due to data entry anomalies. The architecture implementation supports the swapping of matching algorithms by change of run-time parameters.

CDX Gateways enable the interoperation of backend legacy clinical systems with each other and with the RLS through exchange of messages (of various formats) with other gateways using Web services protocols over HTTP transport secured with SSL/TLS (or HTTPS).

6.2 Components and Layers

A logical view of the RLS application architecture was presented in the section 4.

A more detailed breakdown of the components of the RLS, their logical groupings (layers), and implementation platforms used in the prototype project is shown in Figure 19.

Figure 19: RLS and CDX Gateway Components and Sample (Prototype) Implementation Platforms

The diagram shows one EHR node (comprising a clinical system and a gateway) connected to the RLS. One may imagine many such nodes also communicating to the RLS through the Web service interface component in the Integration Broker service of the gateway. CDX Gateways interface with the local clinical systems through the EHR adaptor. A design objective would be to isolate and layer services such that only the adaptor components in the Integration Broker service layer would need to be customized for each site where the Gateway is deployed.

The service layers are independently deployable units, which are orchestrated by a service broker or bus. For example, the security and systems management layers are shared across multiple business application services. Thus, all the service layers are loosely-coupled and reusable. Implementations of RLS may vary based on the specific needs of the site, with the potential for sites to tighten coupling as necessary. They may also use alternate infrastructure services (e.g. security) that conform to local standards as long as they also honor the interface standards used for RLS.

More details of the functionality of each of the components that comprise the service layers are provided in Table 3.

Table 3: CDX Gateway Service / Components Description

Service / Components	Description
Presentation Services	Formats data display to meet end user interaction and display device requirements
Login	Enter username and password to gain access to RLS
Lookup Patient	Patient demographics data entry
Review / Select from Patient Index list	Present list of potential matches of patients to demographics data entered, to be selected from
Request Patient Records	Selection of specific patient medical records to be retrieved from source
View Aggregate Records	Present patient medical records received from multiple sources in common format
Monitor Messages	View log of messages passing through RLS
Manage Access Control Policies	Create and maintain access control policies
Manage User Identities	Create and maintain user identity information and roles to which assigned
Business Application Services	Key functional components that house business rules and execute business logic on clinical data to render it comprehensible to the healthcare practitioner
Patient index	Patient index business object
Medical records aggregation	Application object that merges medical records received from multiple clinical data sources
Medical records request	Standard application object that mediates the data request entered by users on a screen and the data access services
Auditing Services	Support the auditing of access to medical data using logs of all significant events in gateway operations
Medication list	Meds administered business object
Lab / Micro / Radiology	Laboratory, microbiology, radiology results business object
Images and Waveforms	EKG/EEG graphs, Radiology imaging etc.
Notes / Reports	Clinical documentation business object
Visit History	Patient encounters business object
Problem list	List of current diagnoses business object
Data Management Services	Manage application access to data storage and processing of data in data storage layer. Isolates the business layer from the details of the data storage service. Supports management of metadata about data stores and repositories in system
Persistence / Data Access	Provide standard data access to business application services that is independent of the underlying data storage technology or database management systems
Code sets and Key management	Manage disparate code sets and generated keys for data imported from multiple systems
Replication, backup, data cache management	Technical data management services. Support data aggregation and asynchronous data streams management Data cache for clinical data (where required).
Data Storage Services	Provide reliable, secure data storage for efficient access by data management services
Data Cache	For storing temporary copies of data retrieved from clinical data sources for faster response to user queries. This could be a significant component for pilot / production implementation since it buffers the clinical data sources from external queries. However, there are significant business and technical issues to be resolved for clinical data caching.
Message store, Logs and Audit	Persistence mechanism for reliable messaging and for monitoring of message flow (may be part of System Management Services)
User directory, Certificates store	Data store for security services layer (may be part of Security Services)
XML Schema and metadata services	Repository of message and data standards for reference—both run time and design time
Integration Broker Services	Manages flow of messages through the Gateway that serves RLS and the clinical systems that communicate with RLS
Message Queuing and Transport	Provides store-and-forward capability and manages connection to messaging infrastructure. Supports asynchronous messaging between loosely coupled services
Message translation	Transform message formats based on mappings
Routing / Orchestration	Routes messages to the appropriate destination channels
Web Services Interface	SOAP and WSDL processing along with other WS-* service implementations, e.g. reliable messaging, error handling, security
XML Processing	Serialization/deserialization of messages, validation of messages against XML schema, and translation from one schema to another using XSLT
HL7 Mapping	Conversion from HL 2.x messages to RLS standard formats (HL7 v3)
EHR Adaptor	EHR system specific component with ability to extract required medical records from EHR system
MPI Adaptor	Component to interface with Master Patient Indexes (including CMPI)
SQL / Replication / ETL Adaptor	Data movement from one data store to another, includes transformation as needed and typically executed in batch (bulk) mode
Systems Management Services	Besides application management functions shown below, extends over the long term to cover remote deployment, configuration, administration and patch application of distributed Gateway from central location
Logging services	Interface for application to log processing events
Exception Handling Services	Interface to raise and manage errors in application processing
Configuration	Interface to manage the configuration of the RLS application. E.g. setting record linking /matching algorithm, logging levels etc.
Security Services	Manage the implementation of security to control access to the system and protect confidentiality and integrity of data in the system
User / Roles Management	Manage the creation, updates, and deletion of actors authorized to use RLS
Authentication / Authorization / Personalization	Validate that actors (user or system) is who/what they claim to be
Consent Management	Manage individual patients consent to let healthcare practitioners view their medical records
Policy Management	Provide interface to configure and manage rules for access to healthcare data, auditing, and secure operation of RLS

The services that make up the Patient Index Service of RLS are described in Table 4.

Table 4: RLS Components Description

Service / Component	Description
Patient Index Services	Maintain patient records sourced from multiple clinical systems and provide access to data
Community Master Patient Index	Multi-enterprise Patient Index data store maintained in the RLS
Patient Records Linking / Indexing	Identify multiple patient records pertaining to the same individual, but created with potentially different attributes
Patient Record Search	Search for index for patients matching the demographic attributes entered by healthcare practitioner

The interfaces between the application components shown are the subject of local implementation decisions. The general bias of SOA-based applications is to use XML messaging interfaces between components. The CDX Gateway integration broker service may be used as a ‘service bus’ that mediates connections between the coarse grained services that make up the SOA-based application. It should be recognized that a messaging interface often has a system performance overhead and that this penalty may not, in some implementations, be fully offset by the benefits of true loose coupling of application components. In such cases, implementations may choose to start with tighter RPC-style interfaces between application components, and migrate to SOA as performance management allows.

6.3 Implementation Topology Options

As shown in the section 5 there are several processing models that can be implemented with the gateway based network architecture. Each gateway is an n-tier application with distinct presentation, application, data storage and integration services. This allows the functionality and data storage at each gateway service to be varied based on the degree of centralization or decentralization desired.

Being based on the Internet, the health information network has a fully connected mesh topology at the transport (and connectivity) level. The application and data distribution across the network nodes determine whether an interaction between nodes is server-based or peer-to-peer. In server-based networks some computers (clients) consume services provided by others (servers). In a peer-to-peer network, the computers on the network can act both as clients and servers, and are referred to as peers. The RLS-based health information network is a hybrid, with some key services (record location) being provided centrally, while others (clinical data exchange) are consumed on a peer-to-peer basis.

RLS’ service oriented application architecture (SOA) and the Web service based network supports multiple application and network configurations with varying degrees of data and application distribution. This derives from the fact that a loosely coupled, peer-to-peer model offers the ability to ‘tighten’ the coupling or centralize the architecture as needed by local implementations, whereas a priori centralization does not offer such flexibility. In effect the RLS-based network leverages the strengths of the Internet where a fully connected network allows varying service topologies to be used based on requirements.

The RLS-based network architecture seeks to find the right balance between being a potential single point of failure in the middle and reducing the processing footprint at the nodes. The proposed SOA model enables the intra-RLS service distribution to be adjusted and tuned for optimal performance at local, regional and national scale.

A case for data decentralization can also be built on patient privacy protection grounds. Recent security episodes and public perception suggest that the likelihood of data spills is reduced by not creating a large centralized repository of patient health information. Leaving protected health information in local clinical systems, and using a federated peer-to-peer clinical data exchange model reduces the likelihood of catastrophic data spills. Where local clinical systems are accessible from the network, the architecture anticipates data being cached by a hosted gateway service, which would serve as a proxy for the legacy clinical system (similar to an application service provider (ASP) model—a hybrid variation on centralized services).

An additional consideration is the messaging architecture for inter-RLS communication. Given that the health information network nodes are all Web-addressable each RLS sub-network node could connect to a remote RLS sub-network node on a peer-to-peer basis. However, as the security discussion indicates the need for each node to authenticate to each other impacts the scalability of such connectivity. An intermediary bridging service is required that can also be provided by the CDX Gateway at the RLS.

The different implementation options are listed in Table 5 below.

Table 5: Implementation Topology Options

Implementation Topology	Description	Decision Criteria
Peer-to-peer using gateways for transport mediation and aggregation	Clinical data are distributed and managed within their clinical systems Central patient registry for record location Gateways translate messages from local to network standard format Message and data aggregation at each gateway node	Service oriented architecture provides maximum flexibility in linking disparate systems No single point of failure (SPOF) No centralized command and control Increased mediation / aggregation functionality at Gateway … complex distributed administration
Peer-to-peer with gateways maintaining clinical data caches	Gateways in addition to facilitating interconnectivity also serve as proxies for clinical data stores	Clinical data sources maintain autonomy Operational clinical systems are not subject to unpredictable query loads from network users Data replication needs to be set up and maintained between clinical database and proxy cache
Hub and spoke with distributed data sources using central mediation service for message routing	While clinical data remains at network nodes, messages are all routed through a central service Central service handles message and data aggregation	The gateway at the RLS could serve as the central routing and mediation service Lighter weight gateways at the edges minimize network joining overhead
Hub and spoke with central data repository	Variation of the distributed proxy data cache wherein data from clinical data sources are moved to central data repository Gateway function is purely transport mediation	Increased central data management and security overhead Reduced participation rates from clinical enterprises Very light-weight distributed gateway High degree of data conformity required
Inter-RLS data sharing on a peer-to-peer basis	Use Gateway service at each clinical system to communicate across RLS sub-networks	Sharing of information across communities needs to be independent of data distribution with the RLS sub-network Trust relationships need to be built on very large scale across all nodes in all sub-networks
Inter-RLS data sharing using a ‘central’ intermediary service	Use the RLS Gateway to provide intermediary services to mediate patient lookup and clinical data exchange between different sub-networks	Trust relationships need exist only within an RLS sub-network and between RLSs

Centralization and distribution are relative concepts and network topologies typically exist somewhere on a continuum between the two. The RLS architecture principle of federated data and centralized directories is currently considered best practice, but may well need to adapt to different models as technologies evolve. The above list of possible implementation options shows that the proposed architecture is flexible and adaptive.

6.4 Security Model

The RLS architecture principles recommend a delegated authentication model as the most practical approach to achieving the rigorous security and privacy demands on a health information network. Users are authenticated at the gateway service that they use to connect to RLS. Each gateway service is a full member of the clinical enterprise trust domain where it is deployed. Users wishing to access the health information network have their identity and authorization verified by enterprise security processes integrated with the gateway service.

Delegated enterprise security processes are expected to fully conform to HIPAA regulations and other clinical system and local, regional and national security requirements. Once authenticated, the user’s identity is embedded in each message flowing through the network, and is logged for comprehensive audit-ability. In addition, the RLS security model calls for authentication of sender and receiver systems using SSL/TLS (or HTTPS) for all messaging interactions. The digital certificates required for SSL/TLS based client and server authentication should be issued by trusted third parties. X.509 certificate life cycle management is recognized as a significant overhead, and automated support is essential as the network expands.

This basic security model that all network nodes must adopt to use RLS is considered adequate for point-to-point (SOAP server to SOAP server) message confidentiality, authentication and integrity. More comprehensive network security covering intermediaries, application-to-application encryption, etc. would need to use message level security.

The RLS security model foresees the migration to WS-Security based authentication across gateway services using XML Digital Signatures and XML Encryption to address confidentiality, authentication, integrity and non-repudiation requirements. WS-Security standards are available for X.509 digital certificate based message signatures and encryption, but implementations are relatively immature. After stabilization of the RLS basic transport level security, implementations should migrate to message level security using WS-Security.

A fully federated architecture would require individual user credentials to be managed at each node, which would pose a significant identity management problem. While federated security standards have been proposed, these are currently not proven in large scale inter-enterprise networks of disparate systems. RLS architecture should, over time, evolve to federated authentication and authorization models using Liberty Identity Federation Framework (ID-FF) and the Secure Assertion Markup Language (SAML) as mature implementations become available.

6.5 Implementation Platforms

There are several platform options available to implement the open standards based RLS architecture. Following the principle of no proprietary technologies, this technical overview does not recommend any specific platform for RLS. As guidance for identifying the appropriate platform-specific tools for the various components of RLS, the discussion below covers the experiences of the prototype development project.

The RLS prototype is developed on the Microsoft .NET platform for local reasons relating to skills and resource availability. The platform choice is based on practical considerations that apply to only RLS prototype development. Other technologies could as well be used, and it is expected that future implementations of RLS are based on other platforms. The choices made for the prototype components and possible alternatives are provided in Table 6.

Table 6: Prototype Platform and Options

Service Layer	Prototype Platform	Alternatives
Presentation Services	ASP.NET	JSP PHP
Business Application Services	.NET components	Java Servlets EJB Session Beans PHP / Python / Perl
Data Management Services	ADO.NET using .NET framework services	EJB Entity Beans Java Servlets PHP / Python / Perl
Data Storage Services	Microsoft SQL Server 2000	Oracle DBMS IBM DB2 MySQL PostgreSQL
Integration Broker Services	Microsoft BizTalk Server 2004	BEA WebLogic Integrator IBM WebSphere / Mercator InterSystems Ensemble Orion Symphonia SeeBeyond eGate Combination of Enterprise Service Bus (Sonic MQ) and XML utilities (Altova XML Suite)
Adaptor Services	Custom components built on BizTalk framework	Packaged adaptors from Integration broker vendors above
Messaging Services	Microsoft BizTalk Server 2004, which uses MSMQ	IBM WebSphere MQ
Systems Management Services	Custom .NET components using .NET framework	CA Unicenter IBM Tivoli Microsoft Management Services
Security Services	Custom .NET components using simple database table for user identities / credentials	Novell Odyssey Sun ONE CA eTrust

6.6 Interconnectivity and Data Standards

Standards play a central role in the interoperability framework that RLS is part of. Policies and data standards may be considered the two pillars of the healthcare information network interoperability architecture. Technical standards that underpin the RLS-based common framework are described here.

While the healthcare industry in the US has no shortage of data exchange standards, clinical systems interoperability remains a major challenge. The problem is more one of choosing from several candidate offerings from various standards development organizations, and specifying coherent interoperability profiles that are easy to implement.

Interoperability standards can be specified across technology, data, application and organizational domains. Given the restricted problem domain of RLS, the common framework focuses on standards that are directly relevant to the use cases within RLS’ immediate scope. To advance decoupled development of interoperable systems and rapid adoption of the data sharing architectures, the RLS specification seeks to cover a minimum set of standards rather than make “all or nothing” recommendations.

At a high level, system interoperability standards may classified under the following categories:

• Domain Data Content and Structure Standards: includes information models, data naming standards, and controlled vocabularies. These represent semantic specifications that support business process level interoperability
• Messaging and Transport Standards: covering message packaging, transport and network protocols. These may be considered more in the realm of syntactic standards that support technical interoperability

As implied by its name various domain standards exist for the different clinical domains of data to be shared. However, it is possible to standardize on a common messaging and transport protocol that can be used across all the business domains. The technical standards decision is seen as relatively less contentious and will be discussed first.

6.6.1 Messaging and Transport Standards

Given the architectural principle to use open standards and the Internet for connectivity, the RLS uses Web services as the transport layer standard. This determination drives a range of other standards, which may be represented in the form of a technology stack. A common view of the ‘Web services stack’ is shown in Figure 20.¹⁵

Figure 20: Web Services Stack

At the base of the stack are the HTTP and URI standards. The World Wide Web is evidence of the massive scale interoperability engendered by just these two enabling standards. Web services, based on SOAP (message packaging) and WSDL (message exchange contract) format standards, which in turn use XML and XML Schema as message notation and description standards, leverage transport layer interconnectivity to connect the data and application layers. Other technologies that are in wide-spread use and integrated in XML based messaging are XML Namespaces, XPath, and XSL. The other functional boxes in the stack have associated standards as well, but these do not have as high a degree of industry consensus about them.

Given the varying stages of approval and acceptance of the various standards in the stack, RLS needs to focus on the essential protocols that support interconnectivity while presenting the lowest adoption overhead to network participants. The Web Services Interoperability (WS-I) Organization provides a profile that focuses on the core Web services specs such as WSDL and SOAP, and addresses known interoperability issues. More specifically, the ‘Basic Profile’ provides specific implementation guidance on the core Web services standards that should be used together to develop interoperable Web services. Implementers thereby have higher confidence on achieving interoperability using Web services products from different vendors. The WS-I Basic Profile 1.1¹⁶ offers the best choice for a candidate stack that RLS should adopt, and track as it evolves with the national (and global) technology environment.

In addition, WS-I has published a draft Basic Security Profile that should be used in implementing WS-Security based services.¹⁷ The advantages of using the WS-I profiles include reuse of tools, implementation guides, and reduced costs, complexity and risks. A more restricted Web services stack with specifications that conform to the WS-I Basic Profile, is shown in Figure 21.

Figure 21: WS-I Basic Profile Web Services Stack

RLS uses the WS-I Basic Profile as its core messaging and transport services standards suite. Web services specifications providing standard XML grammars for the other functions in the technology stack are growing and some (e.g. BPEL for process orchestration) are strong candidates to become mainstream standards in the near term.

As RLS grows functionally the appropriate specifications should be reviewed and incorporated into the standards stack. Ideally, this evolution of RLS standards should leverage profiles developed by WS-I, or other interoperability standards organizations. WS-I is currently engaged in updating the Basic Profile to include SOAP v1.2 and WSDL v2.0 which offer significant functionality improvements over the current versions in the profile. RLS implementations should develop migration strategies to SOAP v1.2 and WSDL v2.0, so that the added benefits from the new features can be availed.

An alternate XML based business to business messaging frameworks with strong claims to being ‘industry standard’ is OASYS’ Electronic Business using eXtensible Markup Language (ebXML) framework.¹⁸ ebXML has been adopted by, among other, the U.S. Department of Defense for EMall, Center for Disease Control and Prevention (CDC) Public Health Information Network (PHIN), and NHS (UK) National Program for Information Technology (NPfIT). While the corresponding WS-* standards are maturing, as of this writing ebXML is clearly ahead in terms of stable specifications for reliable messaging, security, and exception handling. However, the rate of uptake of WS-* across the US market is higher than ebXML, particularly among applications and tools vendors. The perception that ebXML carries major implementation overhead has inhibited its use particularly among smaller organizations.

There are significant commonalities between the standards suggested for RLS and the PHIN ebXML stack. ebXML wraps another envelope on a SOAP message, and there is overlap between WSDL and ebXML’s CPPA, as well as between UDDI and the ebXML registry. The RLS architecture is extensible to support ebXML based messaging, through extension of the Gateway Integration Services layer to include an ebMS type messaging adaptor.

6.6.2 Domain Data Standards

Having fixed on the Web services stack as its data transport standards RLS offers significant flexibility in choice of domain data standards. The primary use cases that RLS supports deal with publishing and looking up patient demographic information. The leading information model standard for patient information is the HL7 Reference Information Model (RIM), which is the basis for the new HL7 v3 message formats definition. RLS uses the HL7 RIM as the basis for data standards. RLS adopts a HL7 v3 message format for the various interactions it supports. Given the prevalence of HL7 v2.x messaging in the healthcare industry in the US, RLS also supports a 2.4 (XML) based message format. Details are provided in the RLS Communication Messaging Implementation Guide.

In general information exchange between nodes in the healthcare network may be visualized as occurring over a multi-layered set of standards, as shown in Figure 22.

Figure 22: Interoperability Network Layers

EHR information in the RLS context refers specifically to patient demographic and identifier information. The same stack is applicable to general clinical data exchange in the healthcare information network. The domain data standards would be mostly drawn from the available HL7 format standards. However, legacy data formats need to be catered to such as NCPDP Script for prescription medication data, and DICOM for radiology imaging.

The interoperability framework is focused on messaging and data standards. This is in keeping with the SOA principle that interfaces trump implementation. The internal implementation details of the RLS Patient Index service or Gateway service are not relevant to the interoperability of the different network nodes. The two interfaces internal to a network node are:

• User access to the RLS is from standard Web-browser clients that invoke presentation services from the CDX Gateway servers. The user interface is generated in strict XHTML so that enterprises can use CSS and XSL style sheets to customize the user experience as necessary.
• Gateway services interface with the local clinical data systems through standards interfaces such as HL7 messaging, or SQL database queries. If the Gateway is to serve as a clinical data cache to offload queries from the transaction clinical system, then data feeds need to be built to move clinical data into the Gateway data cache.

6.6.3 Comprehensive Standards List

The full suite of standards covering support functions for RLS implementation and use in the healthcare information network is listed in Table 7.

Table 7: List of Standards

Component	Specification	Comments
Hypertext Transport	HTTP/1.1: RFC 3818	Base message transport layered on TCP/IP
Directory access	LDAP v3
Domain name services	RFC 1035
Transport security	SSL v3 / TLS 1.0
Encryption algorithm	3DES
Message Hashing	SHA256
Message Signing	RSA FIPS 186-2
Web service message	SOAP v1.1	Upgrade to SOAP v1.2
Web services description	WSDL 1.1	Upgrade to WSDL 1.2
Web services basic interoperability profile	WS-I Basic Profile 1.1
Web services choreography	BPEL4WS
Web services security	WS-Security
Web services addressing	WS-Addressing
Data integration metadata / metalanguage	XML 1.0	Legacy formats (e.g. HL7 v2.x, NCPDP) do not all use XML.
Data integration metadata definition	XML Schema 1.0	Non-XML based messages do not have a standard schema notation
Data transformation	XSL: Extensible Stylesheet language, http://www.w3c.org/TR/xsl
Data modeling language	UML
Data model exchange	XMI	XML based metadata interchange
Message signatures	XML Signature	Signatures are embedded in the SOAP Header
Message encryption	XML Encryption	Encryption information is provided in SOAP Header
Registered namespaces	URI (Uniform Resource Identifier) http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/	URN: form of URI which uses a namespace for persistent object names
Scheme for site identification on the WWW	URL (Uniform Resource Locator): address of a resource which is retrievable using the Internet. http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/
Identifiers using ASN.1	Object Identifier (OIDs) http://www.iso.org/iso/home.htm
Scripting	ECMA 262 Script http://www.ecma-international.org/publications/standards/ECMA-262.HTM
Domain data	Health Level Seven (HL7) v3
Clinical Terminology	SNOMED Sponsor: NLM (sourced from College of American Pathologists)	Clinical Terms creates a single unified terminology to underpin the development of the integrated electronic patient record by providing an essential building block for a common computerized language for use across the world