An OpenHealth Service Definition (OHSD) file contains information pertaining to a specific instance of an OpenHealth Service. Information contained in OHSD files include summary information about the service such as the service name, description, version, author info, and service categories. OHSD files can be digitally signed. OHSD files also contain type information for input and output service parameters, as well as optional transformation scripts. OpenHealth Service Definition files are part of the OpenHealth Service Framework. This schema specifies the format for all OHSD files. The format types are specified with MIME types (see http://www.iana.org/assignments/media-types/). Many types needed to support the exchange of health-related content, however, are not included in the standard set of MIME types. Some well-known types are listed below (in the Type field). Other future types might include ACCOUNT#, BILLING_INFORMATION, and other basic types that may be needed to augment CCR data in common transactions. Note that applications recieving data in a type not listed below may look up the argument type and how to display it in their computer's registry. Predefined (well known) values: application/x-ccr (CCR 1.0 file) text/html (HTML) application/pdf (Adobe PDF) application/x-url (A url to a web page containing a user-readable result) Used in conjunction with DataElement, which contains both a StringValue and a base64Value fields. When sending a value through SOAP using the WSDL type DataElement - which field of the DataElement should be set? Set the StringValue or base64Value? Or - allow ANY. If not specified, assume it can be ANY. Predefined (well known) values: StringValue base64Value ANY (default value if this encoding is not specified.) This file suffix field (like .x12-837) is used to register in the operating system an association between the given MIME Content-Type and this file suffix. Its optional, but helpful, if you wish to have a client application automatically recognize files of the given type (suffix) - for example - for a source for Translation Service - like X12-837. Most OpenHealth services take a single input and produce a single output, but this abstraction allows for multiple inputs and multiple outputs. The point of this is - for example - to allow a service which merged two documents, or a service which produced both a printed report and a CCR as output. There is almost always just one of these, but it could be omitted or occur multiple times. if ommitted, this defaults to 1 if ommitted, this defaults to 1. If you specify a maxOccurs > 1, then arguments can either be distinguished by order, or by name The Header contains descriptive and copyright information about this OpenHealth Service. Short name of the OpenHealth Service (roughly 100 characters or less) Long (or full) name of the OpenHealth Service. This can be up to (perhaps) 1000 characters. If this is empty - it is treated as the same as 'ShortName'. Detailed desciption of the OpenHealth Service. This section documents information about the version of this OpenHealth Service. The FamilyGUID is used to maintain the identify of the service across versions. The FamilyGUID should NOT change when the version number changes. To fully identify a service use the VersionInfo/FamilyGUID (along with its version#). Specify type of OpenHealth Service, and any flags that might control how they are used and behave. For example, this can be set to Report, Expenses, Translation Service (TranslationService), De-Identification Service (DeIdentificationService), Queueing Service (QueueingService), Summary, Graph, Common Form (CommonForm), Medical Decision Support (ClinicalDirectivesAndRecommendations), Explicit Submission Required (ExplicitSubmitRequired) , etc. See the OpenHealth SDK documentation for details on each of these. Also note that you can (and typically will) specify multiple Categories. See http://www.w3.org/Signature/, http://www.xml.com/lpt/a/2001/08/08/xmldsig.html, or http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/underxmldigsig.asp for more details. This is a definition of how to transform data locally - on this machine (direct report rather than service based). Examples of valid Type fields include 'http://www.w3.org/1999/XSL/Transform', for XSLT scripts. Examples of valid Encoding fields include 'base64' for base-64 encoded strings. This type of transform is handled via a SOAP call (specify SOAP WSDL). From the user-point of view - there is no obvious difference between local and remote transforms (except possibly the requirement for particular software to be installed on the computer for local transforms and the requirement for network access for remote transforms). Note - RemoteTransformDefinitionType are what are usually referred to as 'services'. An OpenHealth service is a definition of ALL the information needed to map an input document (for example a CCR) to an output document (e.g. another CCR, an HTML document, or a PDF). Note that these OpenHealth Services can run locally (more like a conventional report), or remotely (more like a conventional web service), transparently to the user. A collection of one or more mappings of inputs to outputs. These mappings can run locally, or via a remote service. This can be an arbitrary data set, but will typically be a single CCR This can be an arbitrary dataset, but will typically be a single HTML file, or PDF document. It also - reasonably - could be a combination of a CCR and one of the above reports formats. The value of this element is the encoded procedure to perform this report transformation. Details of how it is to be run/interpretted are encoded in the Type/Encoding attributes.