|
General
Condition
Example
|
XML
|
JSON
|
|
|
PHR
Example
|
XML
|
JSON
|
|
|
Complete
Conformance
Statement
|
XML
|
JSON
|
|
|
EmptyConformanceStatement
|
XML
|
JSON
|
|
6.12.6.1
Terminology
Server
Base
Conformance
Statement
General
|
XML
General
Condition
Example
(id
=
"example")
Raw
|
JSON
| |
|
USLabOrder
Orderer
|
XML
The EHR Server supports the following transactions for the resource Person: read, vread,
update, history, search(name,gender), create and updates.
http://fhir.hl7.org/base/Profilebc054d23-75e1-4dc6-aca5-838b6b1ac81d/history/b5fdd9fc-b021-4ea1-911a
-721a60663796
<!-- the identifier for this conformance statement.
The identifier and version establish identifiers that other specifications etc may
use to
refer to the conformance statement that this resource represents in a logical manner
rather than in a literal (URL) fashion
The identifier should be globally unique - a UUID, an OID, or a URL/URI
-->
This is the FHIR conformance statement for the main EHR at ACME for the private interface
- it does not describe the public interface
<!-- while the FHIR infrastructure is turning over prior to development, a version is
required. Note that this may be rescinded later? -->
<!-- this system can do either xml or json. (Listing both implies full support for either,
with interconversion) -->
<!-- in a real conformance statement, it's unlikely that a single conformance statement
would declare conformance for REST, messaging and documents, though it is legal.
This example does so in order to show all the parts of a conformance statement -->
<!-- this is a server conformance statement. Note that servers are required to provide
one of these. It can easily be edited by hand - copy this, replace the metadata
above,
delete the messaging and document stuff below, and then replace the details appropriately.
-->
<!-- let's assume that HL7 has stood up a profile registry at http://fhir.hl7.org/fhir
- it's likely to have a registry, though this is not decided, nor is a URL decided.
This application simply uses a profile registered directly with HL7. For the simplest
case of a FHIR REST Server, just delete this profile reference. Profile references
do
not need to be a UUID, though a profile registry could insist that they are -->
<!-- a messaging conformance statement. Applications are not required to make a conformance
statement with regard to messaging, though there is active argument that they should.
-->
<!-- specify a profile for the request person. Very often there's no point profiling
the response, it's not interesting -->
<!-- this is the important element: a reference to a published document profile
note that this is a version specific reference. -->
http://fhir.hl7.org/base/Profilebc054d23-75e1-4dc6-aca5-838b6b1ac81d/history/b5fdd9fc-b021-4ea1-911a
-721a60663796
|
</Conformance>
JSON
|
from
US
Lab
Implementation
Guides
IG
|
|
USLabOrder
Receiver
|
XML
|
JSON
|
from
US
Lab
Implementation
Guides
IG
|
|
USLabReport
Sender
|
XML
|
JSON
|
from
US
Lab
Implementation
Guides
IG
|
|
USLabReport
Receiver
|
XML
|
JSON
|
from
US
Lab
Implementation
Guides
IG
|
|
SDC
Form
authoring
system
|
XML
|
JSON
|
from
Structured
Data
Capture
IG
|
|
SDC
System
for
completing
forms
|
XML
|
JSON
|
from
Structured
Data
Capture
IG
|
|
SDC
Repository
for
forms
|
XML
|
JSON
|
from
Structured
Data
Capture
IG
|
|
SDC
Repository
for
completed
forms
|
XML
|
JSON
|
from
Structured
Data
Capture
IG
|
|
SDC
System
for
archiving
and
retrieving
the
completed
forms
|
XML
|
JSON
|
from
Structured
Data
Capture
IG
|
|
SDC
Repository
for
Data
Elements
|
XML
|
JSON
|
from
Structured
Data
Capture
-
Data
Element
Exchange
IG
|
|
SDC
Data
Elements
author/maintenance
system
|
XML
|
JSON
|
from
Structured
Data
Capture
-
Data
Element
Exchange
IG
|
|
XML
|
JSON
|
from
Data
Access
Framework
IG
|
|
XML
|
JSON
|
from
Data
Access
Framework
IG
|
|
System
which
records
information
about
EHR
events
|
XML
|
JSON
|
from
EHRS
Functional
model
-
Record
Lifecycle
Events
IG
|
|
|