Resource
A Resource is a construct defined by the RFH proposal.
See also: SMIRF, a similar construct used by RIMBAA for the purpose of persistence.
Description
Resources represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. This flexibility offers coherent solutions for a range of interoperability problems. The simple direct definitions of the resources are based on thorough requirements gathering, formal analysis and extensive cross-mapping to other relevant standards.
Each resource carries a master id. The id is never changed or reused, and it identifies the resource permanently. Resources may refer to other resources by id knowing that this is stable reference. Each resource has a URL which is derived from the id, the type, and the local base URL. Given one resource address, the address of any other resource can be automatically determined.
Resources contain references to other resources. While each resource can be read and/or changed without explicit reference to these other resources, the presence of these references influences the behaviour of the system: implementations are required to maintain system and data integrity at all times.
Each resource supports the same list of transactions - read, update, delete, etc. One particularly important transaction supported by every resource type is the provision of a conformance statement which specifies what parts of the defined content model are supported by the system, and what other transactions or interactions are supported. If any of the other interactions are supported, the conformance interaction must be supported. (i.e. if the conformance interaction returns an error, no operations are supported).
The exchange specifications are simple and straight forward and based around direct description of the XML representation of the resource. Each resource is described separately, though there are some common patterns used across all the resources (called "data types"). In addition to the simple XML definitions, a schema and UML class diagram are available for each resource. The UML class diagram represents the same logical model as the XML format (though because of UML issues, implementors should not expect the UML model to lead to interoperable implementations).
Further, each xml element (or matching UML class, attribute and composition association) is associated with a reference into a single integrated ontology that serves as a data dictionary. As well as more precisely defining the element, the data dictionary specifies the mappings from the element into other standards.
