SlideShare a Scribd company logo
FHIR for Architects and Developers
Acknowledgements
• Lloyd McKenzie
• Ewout Kramer
• Grahame Grieve
Agenda
• Architectures
• Paradigms
• Resources
• Bundles
• Profiles & Extensions
• Server Notes
• Workflow
• Security
• Tools and Help
• Next steps in New Zealand
Page 2 • HL7 New Zealand
The Spec: Hl7.org/fhir
2
Architectures
Page 4 • HL7 New Zealand
Architectures
• FHIR makes no assumptions about the architectural design
of systems
• You can use it for
– Light or heavy clients
– Central server or peer-to-peer sharing
– Push or pull
– Query or publish/subscribe
– Loosely coupled or tightly coupled environments
 With history tracking (versions) or without
4
Page 5 • HL7 New Zealand
Some possibilities
5
FHIR
Broker
v3
v2
PHR
FHIR
App
Comm.
Interface
DB
FHIR
Page 6 • HL7 New Zealand
Repository model
Vendor Neutral Repository
FHIR
HIS GP PACS SystemX Gateway
FHIR FHIRFHIRFHIR
Page 7 • HL7 New Zealand
Beyond exchange
7
v3
v2
Other
X12
Broker
v3
v2
FHIR
Repository
Decision
Support
FHIR
FHIR
Other
Page 8 • HL7 New Zealand
Bottom Line
• FHIR is a set of tools
– Defined resources
– Extensibility mechanism
– Versioning
– Multi-paradigm
– Set of standard interfaces
– Support for complex services
• Primary purpose is interoperable data exchange
• However, it can be leveraged in many ways
– Many we haven’t even thought of yet . . .
8
Paradigms revisited
Page 10 • HL7 New Zealand
Paradigms
• FHIR supports 4 interoperability paradigms
10
REST Documents
Messages Services
What should you
use when?
Paradigms: REST
Page 12 • HL7 New Zealand
REST
• Simple, out-of-the-box interoperability
• Leverage HTTP: GET, POST, etc.
• Pre-defined operations
– Create, Read, Update, Delete
– Also: History, Read Version, Search, Updates, Validate, Conformance &
Batch (Transaction)
• HTTP Headers for various options
– Like resource format or location
• Response codes to indicate outcome
– OperationOutcome Resource
• Works best in environments where control resides on client
side and trust relationship exists
12
Rest
Page 13 • HL7 New Zealand
Creating & Updating
• POST vs PUT
• Headers
– Request
• Content-type
• Location (for version aware)
– Response
• Content-type
• Others...
• Status messages
– Standard HTTP
• OperationOutcome
• Version aware updates
Page 14 • HL7 New Zealand
Querying by REST
• Base queries
– Simple GET against a resource type
– GET [base]/Patient?name=eve
• Defined rules for query parameters
• More complex
– _include
– Tags
• Queries across reference
– Eg conditions for a patient
– GET [base]/Condition?subject=84238862
– Chained queries
• Compartments
– Syntactic sugar
– GET [base]/Patient/84238862/Condition
Page 15 • HL7 New Zealand
Synchronizing
• History of all resources on server
– GET [base]/fhir/_history
• History of all patient resources on server
– GET [base]/Patient/_history
• History of specific patient on server
– GET [base]/Patient/1/_history
• A history of all changes: inserts, updates and
deletions, ordered by newest first
• Limit with _since and _count
Page 16 • HL7 New Zealand
What’s a ‘deleted’ Resource?
• Delete using DELETE verb
• Trying read operations will return in a 410 (Gone) result in
stead of 404 (Not Found)
• The resource will not be returned by the search operation.
• You can “undelete” by doing an update (PUT) with fresh
content
• Just a “marker” in a resource’s history
Page 17 • HL7 New Zealand
Version history - deletions
33, v12 – 2012-12-04
33, v13 – 2012-12-05
33, v14 – 2012-12-08
/server.org/fhir/Patient/33/_history/12
/server.org/fhir/Patient/33/_history/14
/server.org/fhir/Patient/33/_history/13
/server.org/fhir/Patient/33/_history/15
/server.org/fhir/Patient/33
33, v15 – 2012-12-09
33, v16 – 2012-12-10
DELETION
/server.org/fhir/Patient/33/_history/16
Page 18 • HL7 New Zealand
Version history - revival
33, v13 – 2012-12-05
33, v14 – 2012-12-08
/server.org/fhir/Patient/33/_history/14
/server.org/fhir/Patient/33/_history/13
/server.org/fhir/Patient/33/_history/15
/server.org/fhir/Patient/33
33, v15 – 2012-12-09
33, v16 – 2012-12-10
/server.org/fhir/Patient/33/_history/16
33, v17 – 2012-12-11
/server.org/fhir/Patient/33/_history/17
Page 19 • HL7 New Zealand
Batch
• POST a bundle to server root
• Processed as a transaction
– All succeed, or all fail
• All operations supported
• Different to /message endpoint
– /message allows custom server processing
– Batch is a sequence processed as a transaction
Playing with FHIR
Page 21 • HL7 New Zealand
Test Servers
• Servers
– At least 4 to choose from
– http://spark.furore.com/fhir/Patient/nz100
– http://fhir.healthintersections.com.au/open/Patient/100
– fhir.orionhealth.com/blaze/fhir/Patient
– https://his-medicomp-gateway.orionhealth.com/blaze/fhir/metadata
• Tools
– XML Editor (Oxygen)
– REST Client (POSTMan)
21
Script
• Search patient on name
• GET single patient from list
• XML & JSON
• Update and PUT back
• repeat REST Search
• Show error
Page 22 • HL7 New Zealand
When to use REST?
• Want low coupling between systems
– In theory, very little up-front negotiation required
• Small, light-weight exchanges
• Focus is CRUD operations
– Also for publish/subscribe
• Client-driven client-server orchestration
• Server endpoint has fixed location
• Well-suited for Mobile, PHR, Registries
22
Rest
Page 23 • HL7 New Zealand
When to avoid REST?
• Complex or server-driven orchestration
– Order of operations matters (e.g. complex decision support)
• Unit of work != resource
– “Transaction” may be an option
• Lack of trust in the client for audit, etc.
23
Rest
Paradigms: Documents
Page 25 • HL7 New Zealand
Documents
• Similar to CDA
• Collection of resources bound together
– Root is a “Composition” resource
– Just like CDA header
• Sent as an ATOM feed
– Usually stored as binary blob
– Can be separate resource with Composition as ‘entry’ point
• One context
– Not propagated
• Can be signed, authenticated, etc.
• Working on conversion between FHIR Doc & CDA
25
Documents
Page 26 • HL7 New Zealand
Documents – are bundles
26
Observation
Resource
Composition Resource
Section
Section
Device Resource
Patient Resource
Prescription
Resource
<feed>
<entry>
<Composition />
</entry>
<entry>
<Observation />
</entry>
<entry>
<Device />
</entry>
<entry>
<Prescription />
</entry>
<entry>
<Patient />
</entry>
</feed>
AttesterMetadata
Page 27 • HL7 New Zealand
The Composition resource
27
Page 28 • HL7 New Zealand
Document Management
• The DocumentReference resource
– Enables ‘XDS-like’ services
• The ‘registry’ is just a FHIR server
– Same query capabilities
• Point to document
– Any document (FHIR Doc, CDA, PDF etc).
Page 30 • HL7 New Zealand
XDS FHIR Style (MDS)
Page 31 • HL7 New Zealand
When to use Documents?
• No different to CDA
• Focus is on persistence
• No workflow involved
– other than post/retrieve document
• Need tight rules over authenticated content
• Want to communicate multiple resources with control over
how data is presented
• Data spans multiple resources
31
Documents
Page 32 • HL7 New Zealand
When to avoid Documents?
• Need for workflow
– Request/response, decision support
• Data is dynamic
– I.e. want view of data now, not at time of authorship
– Multiple contributors over time
• Resources need to be accessed/manipulated independently
32
Documents
Paradigms: Messages
Page 34 • HL7 New Zealand
Messages
• Similar to v2 and v3 messaging
• Also a collection of resources as an ATOM feed
• Allows request/response behavior with bundles for both
request and response
– /message endpoint on REST server
• Event-driven
– E.g. Send lab order, get back result
• Can be asynchronous
34
Messages
Page 35 • HL7 New Zealand
Messages – are bundles
35
Observation
Resource
MessageHeader
source destination
Device Resource
Patient Resource
<feed>
<entry>
<MessageHeader />
</entry>
<entry>
<Observation />
</entry>
<entry>
<Patient />
</entry>
<entry>
<Device />
</entry>
</feed>
event
Page 36 • HL7 New Zealand
MessageHeader Resource
36
Resource used in both request & response
Page 37 • HL7 New Zealand
FHIR messages
• No storage of the “Message” resource implied. Might be used
in a router, converted to v2, etc.
• The server can process them based on the event code and
return the response as another message (again a bundle).
37
Page 38 • HL7 New Zealand
Communicating messages
• Message Exchange Pattern
• Synchronous in standard
• Async supported
• Reliability
• Transport
• REST supported but, you can send FHIR Messages over mail, MLLP,
TCP, IPoAC (or Healthlink!)
• FHIR defines an HTTP end-point for messages
• http://server.org/fhir/Mailbox
• Response comes back in the acknowledgment payload
38
Page 39 • HL7 New Zealand
Revisiting the Immunization Forecast
TCH ForecasterFHIR ServerFHIR Client
TCH Forecaster
with FHIR Message InterfaceFHIR Client
Page 40 • HL7 New Zealand
When to use Messaging?
• Request/response workflow
• Need to drive behaviors more complex than CRUD on a
single resource
– E.g. merge, complex queries
• Need for asynchronous communications
• Need to communicate information about many resources
but want to minimize exchanges
• No “identity” for many resources
40
Messages
Page 41 • HL7 New Zealand
When to avoid Messaging?
• Precise control required on how data gets
persisted/displayed to humans
• Need for lightweight communications
• Want to avoid pre-negotiations on behavior
41
Messages
Paradigms: Services
Page 43 • HL7 New Zealand
Service Oriented Architecture (SOA)
• Do whatever you like
– (based on SOA principles)
– Ultra complex workflows
– Ultra simple workflows
– Individual resources or collections (in Atom or other formats)
– Use HTTP or use something else
– Only constraint is that you’re passing around FHIR resources in some
shape or manner
43
Services
Page 44 • HL7 New Zealand
When to use Services?
• All previous paradigms are a type of services interface
• Use a custom service when capabilities of other paradigms
don’t fit requirement
– Operations other than CRUD on a resource (e.g. decision support)
– Workflow more complex than simple request/response
– Need to mix document persistence with
behavior
44
Services
Page 45 • HL7 New Zealand
When not to use services?
• When something else will do the job as well
– I.e. Don’t define a custom service for something that already naturally
is handled by REST, messaging, etc.
45
Services
Page 46 • HL7 New Zealand
Paradigm guidance
• No absolutes
– Consider a “when to avoid” as a note of caution
– Capabilities/architecture of legacy will often drive approach,
particularly initially
• E.g. If v2 back end, messaging
– Architectures will be driven by legacy requirements, architectural
preferences, enterprise architecture commitments, etc.
46
Page 47 • HL7 New Zealand
Combining paradigms
• No requirement for a system to only support one paradigm
– E.g. hospital may be primarily messaging, but use documents for
discharge summaries and reports and expose registries and
appointments via REST with a few custom services for decision
support or specialized workflow
• Data (generally) shared easily across paradigm boundaries
• Caveats:
– If updates come in via document, message or service, RESTful version
id still needs to increment
– Documents should typically be persisted whole, not reconstituted
from parts
• Ensures signature validity
– Legacy messaging systems may not provide the metadata to easily
expose or manipulate discrete resources via REST
47
Resources in more detail
Page 49 • HL7 New Zealand
Resource Definition
• Every resource definition has:
– Scope and use
– ‘UML’ representtaion
– XML representation
– Bindings
– Constraints
– Resource specific notes
– Examples
• And computable
– XSD Schema
– schematron
Page 50 • HL7 New Zealand
XML & JSON
<Patient xmlns="http://hl7.org/fhir">
<text>
<status value="generated" />
<div
xmlns="http://www.w3.org/1999/xhtml">Doe,
John</div>
</text>
<identifier>
<label value="NI" />
<system
value="http://moh.govt.nz/fhir/patient/nhi" />
<value value="PRP1660" />
</identifier>
<name>
<use value="official" />
<family value="Garrett" />
<given value="Gordon" />
</name>
</Patient>
{
"resourceType": "Patient",
"text": {
"status": "generated",
"div": "<div
xmlns="http://www.w3.org/1999/xhtml">Doe,
John</div>"
},
"identifier": [
{
"label": "NI",
"system": "http://moh.govt.nz/fhir/patient/nhi",
"value": "PRP1660"
}
],
"name": [
{
"use": "official",
"family": [
"Garrett"
],
"given": [
"Gordon"
]
}
]
}
Page 51 • HL7 New Zealand
Specify format using REST
GET /fhir/Patient/1?_format=json HTTP/1.1
HTTP/1.1 200 OK
Content-Type: application/json+fhir;charset=utf-8
Content-Length: 787
GET /fhir/Patient/1 HTTP/1.1
Accept: application/json+fhir
HTTP/1.1 200 OK
Content-Type: application/json+fhir;charset=utf-8
Content-Length: 787
Same for Create/Update
Page 52 • HL7 New Zealand
Resource metadata
Patient
MRN 22234
“Ewout Kramer”
30-11-1972
Amsterdam
Metadata
Resource Identities
http://fhir.hl7.org/Patient/23E455A3B
http://fhir.hl7.org/Patient/23E455A3B/_his
Last updated
2013-12-23T23:33:01+01:00
http://hl7.org/fhir/tag/profile
http://hl7.org/fhir/Profile/us-core
http://hl7.org/fhir/tag
http://example.org/fhir/Status#Test
Page 54 • HL7 New Zealand
Identity
• 2 different ‘sorts’ of identity
– ID identifies a resource on a server
• Is metadata
• Will change between servers
– Identifier
• Business identifier
• Is an element in the resource
Page 55 • HL7 New Zealand
A Resource’s ID
• In fact: an URL
– http://server.org/fhir/Patient/1
endpoint
resource type
identifier
Note: This URL resolves to the current version of a resource
It’s also specific to a server
Page 56 • HL7 New Zealand
“Business” identifiers
Page 58 • HL7 New Zealand
Narrative
Page 59 • HL7 New Zealand
Tags
• Contain metadata about resources
– Beyond ID, version & date
• Used for different purposes:
– Compliance to Profile
– Security – e.g. sensitivity of resource
– Indicate Document/Message
– User defined
• Transported in different ways:
– REST – as an HTTP header
– In a bundle (document, message, transaction) - in the feed.category
element
Page 60 • HL7 New Zealand
Versioning
• Most recent version
– http://server.org/fhir/Patient/1
– Returns single resource
• All versions
– http://server.org/fhir/Patient/1/_history
– Returns bundle of versions
• Specific version
– http://server.org/fhir/Patient/1/_history/_1
– Returns single resource
• Version support is optional
• Works at instance and type level
Page 61 • HL7 New Zealand
Resource Reference
Example: part of DiagnosticReport
Page 62 • HL7 New Zealand
Coded values: the ValueSet resource
• Most coded elements have a set of possible values
– Large or small
– Static
• (change slowly)
• Can use ValueSet resource to define set of possibilities
– A “true” FHIR ValueSet resource (may be version specific)
• Can contain:
– References to a terminology (like SNOMED)
– A list of specific codes
• Examples
– International examples
• All the HL7 version 2 ‘tables’
– NZ Examples
• Iwi & Hapu
• DHB’s
62
Page 63 • HL7 New Zealand
Example of ValueSet
<?xml version="1.0" encoding="UTF-8"?>
<ValueSet xmlns="http://hl7.org/fhir">
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">The value set for confidentiality codes in the elbonian docume
project. The codes are defined directly by the valueset, rather than references to an external terminology</d
</text>
<name value="ConfidentialityOptions"/>
<description value="ConfidentialityOptions"/>
<status value="draft"/>
<!-- Define the options in the resource rather than an external terminology-->
<define>
<system value="http://fhir.moh.elbonia.com/confidentiality"/>
<concept>
<code value='N'/>
<display value="Normal"/>
<definition value="That the document is of normal confidentiality "/>
</concept>
<concept>
<code value='H'/>
<display value="High"/>
<definition value=”That the document is Highly confidential - eg Mental health "/>
</concept>
</define>
</ValueSet>
Page 64 • HL7 New Zealand
Contained resources
• When the contained
resource has no separate
identity
• Has quite a few limitations
• Use sparingly
– Bundle always better if
possible
<Composition
xmlns="http://hl7.org/fhir">
<extension>...</extension>
<text>...</text>
<contained>
<Organization id="org1">
<!– other data -->
</Organization>
</contained>
<information>
<!-- other attributes -->
<custodian>
<reference value="#org1" />
</custodian>
<!-- other attributes -->
<information>
</Document>
Bundles in more detail
Page 66 • HL7 New Zealand
Review
• Atom as the bundling mechanism
– Query results
– Document
– Message
• Request & Response
– Batch/Transactions
• XML or JSON
– Conversion routines available
– (Can’t use ordinary ones)
• Use tags to identify Documents & Messages
– First resource significant
Page 67 • HL7 New Zealand
Page 68 • HL7 New Zealand
Resource Entry
Version-specific id
Resource id
Last modified
Resource content
Human-readable form,
just like Resource.text
Tags
Page 69 • HL7 New Zealand
Bundle as a serialized Object Graph
Profiles and Extensions:Profiles
Page 71 • HL7 New Zealand
The need for Profiles
• Many different contexts in healthcare, but a single set of
Resources
– A desire to keep the resources manageable
– Most elements in base resources optional
• Need to be able to:
– Describe restrictions based on use and context
– Support elements not in the core resource
• Allow for these usage statements to:
– Authored in a structured manner
– Published in a repository
– Discoverable at Design and Run-time
– Used as the basis for validation, code, report and UI generation.
71
Page 72 • HL7 New Zealand
Profiling a resource. For example...
72
Require that the identifier uses the
NHI – and is required
Limit names to just 1 (instead of 0..*)
Limit maritalStatus to another set of
codes that extends the one from
HL7 international
Add an extension to support “Iwi”
Note: hardly any
mandatory
elements in the
Page 73 • HL7 New Zealand
Capabilities of Profiles
• Descriptive
– Information about the Profile (what, why, who)
• Extending a resource
– Adding new elements
– Same capabilities/datatypes as existing ones
• Constraining a resource
– Specifying datatypes for an element
– Modifying datatypes (eg translations)
– Defining terminology bindings
– Specifying multiplicity (eg make an element required)
– Further refining repeating values (‘Slicing’)
• Example of Composition.section (Document)
– Cannot specify default values for resource instances
• Everything explicit in an instance
Page 74 • HL7 New Zealand
Structured & published
• A Profile is just a “normal” Resource
• Any FHIR server could serve Profiles (just like Patients, Observations,
etc…)
• So, any FHIR server is a profile repository!
• A profile is simply referred to by its URI:
– Like any other resource
• e.g. http://hl7.org/fhir/Profile/iso-21090
– Extensions in an ‘instance’ of a resource refer to the profile that defined
them using the URI
– Need to think about re-usability when designing profiles
74
Page 75 • HL7 New Zealand
Who publishes a Profile?
http://www.hl7.org/fhir/Profile/iso
-21090
http://www.hl7org.nz/fhir/Profile/
patient
http://www.health4all.org/fhir/Pro
file/
Page 76 • HL7 New Zealand
Using profiles
• If we are a server then a client can read our conformance
resource, which will list the profiles we support, and provide a link
to them.
– Conformance also has other functions like specifying supported resources,
operations on those resources & interoperability paradigms
• If we are a client, we can tell a server that we conform to a profile
using a tag (the server will probably still check).
– We could also ask a server just to validate
– Could set up ‘distributed’ validation with (eg) National Validation servers
used by local/regional servers
• If we receive a resource with an extension we don’t recognize, it
will point to the profile in which it is described so we can decide
what to do with it.
– Note that a single resource can reference different profiles
76
Page 77 • HL7 New Zealand
What’s in a profile, and its relationships?
77
Descriptive
Identifier
Name, Version
Publisher
Description, Code
Status
Date (of publication)
Resource and
Datatype
Constraints
Extension
Definition
Conformance
(server)
Resource
(via Tag)
ValueSet
ValueSet
Extension in
Resource
Tag
Page 78 • HL7 New Zealand
Scale / design
• Make a profile with just extensions
• Make a profile with just 1 resource + extensions on that
resource
• Make a profile with all (say national) resources + extensions.
78
Page 79 • HL7 New Zealand
Profile Descriptive information
• To describe the purpose of the Profile
• To help with location
• Details
– Identifier: Universally unique identifier, assigned by author value=“urn:hl7.org:extensions:iso-21090“
or “2.16.840.1.113883.10.20.2.1”
– Version: Version of the profile, manually maintained by author. Suggested format: a timestamp (e.g.
2013-01-01T12:34:45)
– Name: Free natural text name (e.g. “Extensions to support Orion Medications”)
– Publisher: organization or individual responsible for publishing. Should be populated (e.g. “FHIR
Project Team“)
– Telecom: one or more contact points of the publisher (telephone, email, website etc)
– Description: longer description of the contents of the profile
– Code: one or more coded descriptions to help with finding the profile
– Status (fixed choice of draft, active, retired) + experimental Y/N
– Requirements: scope & usage (the “need” or “why” of the profile)
– Date (of publication), e.g. “2013-07-07"
79
Page 80 • HL7 New Zealand
Constraining Structures (elements)
• Defining terminology bindings
– ValueSet is useful
• Specify element datatypes
• Further refining repeating values (‘Slicing’)
• Specifying multiplicity
From the spec
Possibilities
Page 81 • HL7 New Zealand
Profile example
Medication.code with a defined valueset
Page 82 • HL7 New Zealand
Profile Example
• MedicationPrescription.asNeeded required, and must be
boolean
Page 83 • HL7 New Zealand
Slicing
• Constraining an element with 0..* , 1..*
• FHIR Document as an example
• Composition resource is the CDA Header equivalent
– Composition.section is 0..*
– A CCDA equivalent profile might specify the sections allowed
• Different document types would have a profile
Profiles and Extensions: Extensions
Page 85 • HL7 New Zealand
Extensions
• Resources design for the 80% - Allow easy extension for the
remaining 20% of elements
• Note - You’re not extending a resource per se, but you
specify its characteristics and where an extension may
occur:
– A specific element within a resource
– A specific element within a datatype
– All elements referencing a datatype
– All elements mapping to a specific mapping target
– An extension
Page 86 • HL7 New Zealand
Extensions
• In FHIR, extensions are “normal”
– Consequence of the 80% rule – keep the simple stuff simple
– Extensions can exist anywhere
• Yes, even inside boolean or date
– Conformant systems can’t reject instances just because they contain
unrecognized extensions
– They could:
• Display them
– Should be in resource narrative
• Store as a ‘Blob’
• Make a conscious decision to ignore (unless ModifierExtension)
– (Could lookup profile)
86
Page 87 • HL7 New Zealand
Extension definition
87
Note: multiple
contexts!
Page 88 • HL7 New Zealand
An Extension in a resource
88
Page 89 • HL7 New Zealand
Extending a multiple birth
Key = location of formal definit
Value = value according to definition
Page 90 • HL7 New Zealand
Modifier Extensions
• Also a core part of FHIR
– Needed because some extensions can’t be safely ignored
– Can’t compute on an element containing an unrecognized modifier
extension. However, can:
• Reject instance
• Just display narrative
• Retrieve definition & seek human review
90
Page 91 • HL7 New Zealand
Modifier Extension decisions
• When should you introduce them?
– modifierExtension breaks interoperability so:
• If you can accomplish your objective without one, do that
– Consider a new resource or Other
– Could requirement be met by an element that doesn’t change other
element interpretations?
– Best used when already part of existing practice, but in too narrow an
area to justify being part of core
91
Page 92 • HL7 New Zealand
‘Other’ resource
• When there’s no way to extend an existing one
• Has:
– Identifier
– Code
– Subject
– Author
– Created
• Rest is extensions
• Should discuss with community first
Page 93 • HL7 New Zealand
Designing a Profile
• Define Use Case
• Choose resources
– ‘Other’ if you have to
• Constrain base elements
– Remove
– Make required
– Define ValueSets and bindings
• Define extensions
– Try to re-use existing if possible
– Note ‘hierarchy’ of extensions:
• HL7
• National
• Local
• Build profile
• Publish
Page 94 • HL7 New Zealand
The need for Governance
• Profiles & extensions allow a user to customize their use of
FHIR
• HL7 is establishing publically available registries
– For reference purposes
• With great power...
Page 95 • HL7 New Zealand
Profile editors
• Forge (FHIR.furore.com/forge)
Server specific notes
Page 97 • HL7 New Zealand
Overview of a server
97
HTTP / REST interface Encoding/decoding,
param validation,
syntax validation
Fhir Service
Indexer / Search Storage
Implement service
operations as
described in spec
Page 98 • HL7 New Zealand
From wire to store
Storage
Fhir Service
REST
interface
JSON/XML
POCO/POJ
O
DBMS
O-R Map
FHIR Parser
98
JSON/XML
POCO/POJ
O
Serialize
FHIR Parser
NoSql
(Xml/Json)
JSON/XML
POCO/POJ
O
DBMS
Serialize
FHIR Parser
Page 99 • HL7 New Zealand
Conformance resource
• Allows a server to indicate:
– Metadata about the server
– The resources they support
• The queries against those resources
– The paradigms they support
• REST, messaging, services
– Specific (custom) queries
– The profiles it supports
• Is a normal resource
– Supports discoverability (think UDDI for SOAP)
Page 100 • HL7 New Zealand
Conformance
• Which FHIR version?
• Which resources?
• Which paradigms ?
• What search operations?
• What formats?
• What profiles?
• Is this a test server?
• Who can I contact?
• Do you support History?
• Do you support JSON/XML?
• Is a normal resource
• Supports discoverability (think
UDDI for SOAP)
Page 101 • HL7 New Zealand
Operation Outcome
• When something goes wrong….return the
OperationOutcome Resource!
Page 102 • HL7 New Zealand
Special endpoints
• Binary
– Store/retrieve a blob.
– No query
• Document
– Works at ‘document’ level
– Query on composition
• Mailbox
– Processing endpoint
– Exact actions depending on Trading Partner Agreement
• Note MessageHeader properties – eg event, reason
Workflow
Page 104 • HL7 New Zealand
Workflow
• Resource describe ‘things’
• Workflow says what to do with those things
• Eg
– ePresciption
– Lab order
– Referral
• Order resources
– Order
– OrderResponse
• Combination of Order(for workflow) and specific resource
– Eg Order + MedicationPrescription
Page 105 • HL7 New Zealand
Referrals workflow
105
Security and Privacy
(Coming to the end…)
Page 107 • HL7 New Zealand
Overview
• Signatures
– On bundles
• Tags used to ‘annotate’
resources
– Eg private resource, ‘Special
Patient’
– Application applies policy
• Resources are atomic level
• Some ‘security-related’
resources
– SecurityEvent
– Provenance
• Philosophically FHIR delegates security to infrastructure
– Others do that better
– But does have comments
Page 108 • HL7 New Zealand
Wrapping Up: Tools for Developers
• Specification
– The full specification (included build tools) can be downloaded from the CVS at:
http://gforge.hl7.org/gf/project/fhir
• (Free to download, need account to update)
• Examples
• Validation files
– XSD, Schematron
• Test Servers
– Open source
• Reference Implementations
– Java, .net, Objective-C, javascript
– Open source
– Reference Implementations from www.hl7.org/fhir
• Tooling
– XML/JSON editor
– REST client
108
Page 109 • HL7 New Zealand
Further Information & Help
• Information:
– Specification: www.hl7.org/fhir
• Fully hyper-linked
• Includes many sample files and links to codesets & terminologies
– Wiki pages: http://wiki.hl7.org/index.php?title=FHIR
– HL7 Lists server: from HL7.org
– Blogs (listed on spec)
• Assistance
– ‘Stack Overflow’ – tag hl7-FHIR
– Skpe conversations (email me – david.hay@orionhealth.com to be
included)
Whew! Next Steps in New Zealand?
A group discussion

More Related Content

What's hot

FHIR Documents by Lloyd McKenzie
FHIR Documents by Lloyd McKenzieFHIR Documents by Lloyd McKenzie
FHIR Documents by Lloyd McKenzie
FHIR Developer Days
 
FHIR tutorial - Afternoon
FHIR tutorial - AfternoonFHIR tutorial - Afternoon
FHIR tutorial - Afternoon
Ewout Kramer
 
Terminology, value-sets, codesystems by Lloyd McKenzie
Terminology, value-sets, codesystems by Lloyd McKenzieTerminology, value-sets, codesystems by Lloyd McKenzie
Terminology, value-sets, codesystems by Lloyd McKenzie
FHIR Developer Days
 
FHIR Profiles
FHIR ProfilesFHIR Profiles
FHIR Profiles
David Hay
 
FHIR & Ice
FHIR & IceFHIR & Ice
FHIR & Ice
David Hay
 
Introduction to HL7 FHIR
Introduction to HL7 FHIRIntroduction to HL7 FHIR
Introduction to HL7 FHIR
Health Informatics New Zealand
 
What is FHIR
What is FHIRWhat is FHIR
What is FHIR
Igor Bossenko
 
Fhir basics session4_conformance_and_terminology
Fhir basics session4_conformance_and_terminologyFhir basics session4_conformance_and_terminology
Fhir basics session4_conformance_and_terminology
Kumar Satyam
 
Building an Integrated Healthcare Platform with FHIR®
Building an Integrated Healthcare Platform with FHIR®Building an Integrated Healthcare Platform with FHIR®
Building an Integrated Healthcare Platform with FHIR®
WSO2
 
fhir-documents
fhir-documentsfhir-documents
fhir-documents
DevDays
 
Security in FHIR with OAuth by Grahame Grieve
Security in FHIR with OAuth by Grahame GrieveSecurity in FHIR with OAuth by Grahame Grieve
Security in FHIR with OAuth by Grahame Grieve
FHIR Developer Days
 
Apache Hadoop Security - Ranger
Apache Hadoop Security - RangerApache Hadoop Security - Ranger
Apache Hadoop Security - Ranger
Isheeta Sanghi
 
apidays New York 2022 - Building an API Platform Business, David Mooter, Forr...
apidays New York 2022 - Building an API Platform Business, David Mooter, Forr...apidays New York 2022 - Building an API Platform Business, David Mooter, Forr...
apidays New York 2022 - Building an API Platform Business, David Mooter, Forr...
apidays
 
Couchbase Day
Couchbase DayCouchbase Day
Couchbase Day
Idan Tohami
 
HL7 New Zealand: FHIR for developers
HL7 New Zealand: FHIR for developersHL7 New Zealand: FHIR for developers
HL7 New Zealand: FHIR for developers
David Hay
 
Transforming Healthcare One API at a Time at Kaiser Permanente
Transforming Healthcare One API at a Time at Kaiser PermanenteTransforming Healthcare One API at a Time at Kaiser Permanente
Transforming Healthcare One API at a Time at Kaiser Permanente
Perficient, Inc.
 
FHIR API for .Net programmers by Mirjam Baltus
FHIR API for .Net programmers by Mirjam BaltusFHIR API for .Net programmers by Mirjam Baltus
FHIR API for .Net programmers by Mirjam Baltus
FHIR Developer Days
 
Dataflow with Apache NiFi
Dataflow with Apache NiFiDataflow with Apache NiFi
Dataflow with Apache NiFi
DataWorks Summit/Hadoop Summit
 
Hadoop Security Architecture
Hadoop Security ArchitectureHadoop Security Architecture
Hadoop Security Architecture
Owen O'Malley
 
FHIR Server Design Review
FHIR Server Design ReviewFHIR Server Design Review
FHIR Server Design Review
Brian Postlethwaite
 

What's hot (20)

FHIR Documents by Lloyd McKenzie
FHIR Documents by Lloyd McKenzieFHIR Documents by Lloyd McKenzie
FHIR Documents by Lloyd McKenzie
 
FHIR tutorial - Afternoon
FHIR tutorial - AfternoonFHIR tutorial - Afternoon
FHIR tutorial - Afternoon
 
Terminology, value-sets, codesystems by Lloyd McKenzie
Terminology, value-sets, codesystems by Lloyd McKenzieTerminology, value-sets, codesystems by Lloyd McKenzie
Terminology, value-sets, codesystems by Lloyd McKenzie
 
FHIR Profiles
FHIR ProfilesFHIR Profiles
FHIR Profiles
 
FHIR & Ice
FHIR & IceFHIR & Ice
FHIR & Ice
 
Introduction to HL7 FHIR
Introduction to HL7 FHIRIntroduction to HL7 FHIR
Introduction to HL7 FHIR
 
What is FHIR
What is FHIRWhat is FHIR
What is FHIR
 
Fhir basics session4_conformance_and_terminology
Fhir basics session4_conformance_and_terminologyFhir basics session4_conformance_and_terminology
Fhir basics session4_conformance_and_terminology
 
Building an Integrated Healthcare Platform with FHIR®
Building an Integrated Healthcare Platform with FHIR®Building an Integrated Healthcare Platform with FHIR®
Building an Integrated Healthcare Platform with FHIR®
 
fhir-documents
fhir-documentsfhir-documents
fhir-documents
 
Security in FHIR with OAuth by Grahame Grieve
Security in FHIR with OAuth by Grahame GrieveSecurity in FHIR with OAuth by Grahame Grieve
Security in FHIR with OAuth by Grahame Grieve
 
Apache Hadoop Security - Ranger
Apache Hadoop Security - RangerApache Hadoop Security - Ranger
Apache Hadoop Security - Ranger
 
apidays New York 2022 - Building an API Platform Business, David Mooter, Forr...
apidays New York 2022 - Building an API Platform Business, David Mooter, Forr...apidays New York 2022 - Building an API Platform Business, David Mooter, Forr...
apidays New York 2022 - Building an API Platform Business, David Mooter, Forr...
 
Couchbase Day
Couchbase DayCouchbase Day
Couchbase Day
 
HL7 New Zealand: FHIR for developers
HL7 New Zealand: FHIR for developersHL7 New Zealand: FHIR for developers
HL7 New Zealand: FHIR for developers
 
Transforming Healthcare One API at a Time at Kaiser Permanente
Transforming Healthcare One API at a Time at Kaiser PermanenteTransforming Healthcare One API at a Time at Kaiser Permanente
Transforming Healthcare One API at a Time at Kaiser Permanente
 
FHIR API for .Net programmers by Mirjam Baltus
FHIR API for .Net programmers by Mirjam BaltusFHIR API for .Net programmers by Mirjam Baltus
FHIR API for .Net programmers by Mirjam Baltus
 
Dataflow with Apache NiFi
Dataflow with Apache NiFiDataflow with Apache NiFi
Dataflow with Apache NiFi
 
Hadoop Security Architecture
Hadoop Security ArchitectureHadoop Security Architecture
Hadoop Security Architecture
 
FHIR Server Design Review
FHIR Server Design ReviewFHIR Server Design Review
FHIR Server Design Review
 

Viewers also liked

Introduction to FHIR - New Zealand Seminar, June 2014
Introduction to FHIR - New Zealand Seminar, June 2014Introduction to FHIR - New Zealand Seminar, June 2014
Introduction to FHIR - New Zealand Seminar, June 2014
David Hay
 
Information Models & FHIR --- It’s all about content!
Information Models & FHIR --- It’s all about content!Information Models & FHIR --- It’s all about content!
Information Models & FHIR --- It’s all about content!
Koray Atalag
 
Potential uses for FHIR in New Zealand by Peter Jordan
Potential uses for FHIR in New Zealand by  Peter JordanPotential uses for FHIR in New Zealand by  Peter Jordan
Potential uses for FHIR in New Zealand by Peter Jordan
David Hay
 
IHE-XDS_XDR-XDM Understanding
IHE-XDS_XDR-XDM UnderstandingIHE-XDS_XDR-XDM Understanding
IHE-XDS_XDR-XDM Understanding
Raghu Kodumuri
 
FHIR architecture overview for non-programmers by René Spronk
FHIR architecture overview for non-programmers by René SpronkFHIR architecture overview for non-programmers by René Spronk
FHIR architecture overview for non-programmers by René Spronk
FHIR Developer Days
 
FHIR API for Java programmers by James Agnew
FHIR API for Java programmers by James AgnewFHIR API for Java programmers by James Agnew
FHIR API for Java programmers by James Agnew
FHIR Developer Days
 
Hl7 reference information model
Hl7 reference information modelHl7 reference information model
Hl7 reference information model
Abdul-Malik Shakir
 
Please don't spell SNOMED with a W
Please don't spell SNOMED with a WPlease don't spell SNOMED with a W
Please don't spell SNOMED with a W
Alastair Kenworthy
 
Hl7 2016 baltimore connectathon provider directories and scheduling
Hl7 2016 baltimore connectathon provider directories and schedulingHl7 2016 baltimore connectathon provider directories and scheduling
Hl7 2016 baltimore connectathon provider directories and scheduling
David Hay
 
ISD2016_Solution_B_Theo_Wilhelm
ISD2016_Solution_B_Theo_WilhelmISD2016_Solution_B_Theo_Wilhelm
ISD2016_Solution_B_Theo_Wilhelm
InfoSocietyDays
 
HIMSS16_IHE USA_Impact of IHE Profiles on Patient Care_Final-Full
HIMSS16_IHE USA_Impact of IHE Profiles on Patient Care_Final-FullHIMSS16_IHE USA_Impact of IHE Profiles on Patient Care_Final-Full
HIMSS16_IHE USA_Impact of IHE Profiles on Patient Care_Final-Full
Seonho Kim
 
Standards-based Solution for National Level Document Sharing.
Standards-based Solution for National Level Document Sharing.Standards-based Solution for National Level Document Sharing.
Standards-based Solution for National Level Document Sharing.
Fòrum Català d’Informació i Salut
 
UIUS Health IT Overview And Capability
UIUS Health IT Overview And CapabilityUIUS Health IT Overview And Capability
UIUS Health IT Overview And Capability
Rajesh Rajasekaran
 
EHR Interoperatbility
EHR InteroperatbilityEHR Interoperatbility
EHR Interoperatbility
Health Informatics New Zealand
 
Hl7 uk fhir the basics
Hl7 uk fhir the basicsHl7 uk fhir the basics
Hl7 uk fhir the basics
Ewout Kramer
 
Health Information Exchange - Trial Implementation Options
Health Information Exchange - Trial Implementation OptionsHealth Information Exchange - Trial Implementation Options
Health Information Exchange - Trial Implementation Options
Health Informatics New Zealand
 
FHIR and DICOM by Marten Smits
FHIR and DICOM by Marten SmitsFHIR and DICOM by Marten Smits
FHIR and DICOM by Marten Smits
FHIR Developer Days
 
Project 2 | Health Care Domain
Project 2 | Health Care DomainProject 2 | Health Care Domain
Project 2 | Health Care Domain
H2kInfosys
 
UCSD NANO106 - 10 - Bonding in Materials
UCSD NANO106 - 10 - Bonding in MaterialsUCSD NANO106 - 10 - Bonding in Materials
UCSD NANO106 - 10 - Bonding in Materials
University of California, San Diego
 
HL7 Standards
HL7 StandardsHL7 Standards

Viewers also liked (20)

Introduction to FHIR - New Zealand Seminar, June 2014
Introduction to FHIR - New Zealand Seminar, June 2014Introduction to FHIR - New Zealand Seminar, June 2014
Introduction to FHIR - New Zealand Seminar, June 2014
 
Information Models & FHIR --- It’s all about content!
Information Models & FHIR --- It’s all about content!Information Models & FHIR --- It’s all about content!
Information Models & FHIR --- It’s all about content!
 
Potential uses for FHIR in New Zealand by Peter Jordan
Potential uses for FHIR in New Zealand by  Peter JordanPotential uses for FHIR in New Zealand by  Peter Jordan
Potential uses for FHIR in New Zealand by Peter Jordan
 
IHE-XDS_XDR-XDM Understanding
IHE-XDS_XDR-XDM UnderstandingIHE-XDS_XDR-XDM Understanding
IHE-XDS_XDR-XDM Understanding
 
FHIR architecture overview for non-programmers by René Spronk
FHIR architecture overview for non-programmers by René SpronkFHIR architecture overview for non-programmers by René Spronk
FHIR architecture overview for non-programmers by René Spronk
 
FHIR API for Java programmers by James Agnew
FHIR API for Java programmers by James AgnewFHIR API for Java programmers by James Agnew
FHIR API for Java programmers by James Agnew
 
Hl7 reference information model
Hl7 reference information modelHl7 reference information model
Hl7 reference information model
 
Please don't spell SNOMED with a W
Please don't spell SNOMED with a WPlease don't spell SNOMED with a W
Please don't spell SNOMED with a W
 
Hl7 2016 baltimore connectathon provider directories and scheduling
Hl7 2016 baltimore connectathon provider directories and schedulingHl7 2016 baltimore connectathon provider directories and scheduling
Hl7 2016 baltimore connectathon provider directories and scheduling
 
ISD2016_Solution_B_Theo_Wilhelm
ISD2016_Solution_B_Theo_WilhelmISD2016_Solution_B_Theo_Wilhelm
ISD2016_Solution_B_Theo_Wilhelm
 
HIMSS16_IHE USA_Impact of IHE Profiles on Patient Care_Final-Full
HIMSS16_IHE USA_Impact of IHE Profiles on Patient Care_Final-FullHIMSS16_IHE USA_Impact of IHE Profiles on Patient Care_Final-Full
HIMSS16_IHE USA_Impact of IHE Profiles on Patient Care_Final-Full
 
Standards-based Solution for National Level Document Sharing.
Standards-based Solution for National Level Document Sharing.Standards-based Solution for National Level Document Sharing.
Standards-based Solution for National Level Document Sharing.
 
UIUS Health IT Overview And Capability
UIUS Health IT Overview And CapabilityUIUS Health IT Overview And Capability
UIUS Health IT Overview And Capability
 
EHR Interoperatbility
EHR InteroperatbilityEHR Interoperatbility
EHR Interoperatbility
 
Hl7 uk fhir the basics
Hl7 uk fhir the basicsHl7 uk fhir the basics
Hl7 uk fhir the basics
 
Health Information Exchange - Trial Implementation Options
Health Information Exchange - Trial Implementation OptionsHealth Information Exchange - Trial Implementation Options
Health Information Exchange - Trial Implementation Options
 
FHIR and DICOM by Marten Smits
FHIR and DICOM by Marten SmitsFHIR and DICOM by Marten Smits
FHIR and DICOM by Marten Smits
 
Project 2 | Health Care Domain
Project 2 | Health Care DomainProject 2 | Health Care Domain
Project 2 | Health Care Domain
 
UCSD NANO106 - 10 - Bonding in Materials
UCSD NANO106 - 10 - Bonding in MaterialsUCSD NANO106 - 10 - Bonding in Materials
UCSD NANO106 - 10 - Bonding in Materials
 
HL7 Standards
HL7 StandardsHL7 Standards
HL7 Standards
 

Similar to FHIR for Architects and Developers - New Zealand Seminar, June 2014

FHIR - as a new currency of exchange in New Zealand
FHIR - as a new currency of exchange in New ZealandFHIR - as a new currency of exchange in New Zealand
FHIR - as a new currency of exchange in New Zealand
David Hay
 
Fire and Ice - FHIR in New Zealand - David Hay
Fire and Ice - FHIR in New Zealand - David HayFire and Ice - FHIR in New Zealand - David Hay
Fire and Ice - FHIR in New Zealand - David Hay
HL7 New Zealand
 
HDFCloud Workshop: HDF5 in the Cloud
HDFCloud Workshop: HDF5 in the CloudHDFCloud Workshop: HDF5 in the Cloud
HDFCloud Workshop: HDF5 in the Cloud
The HDF-EOS Tools and Information Center
 
HL7 FHIR FoundationTopics for Non-Developers
HL7 FHIR FoundationTopics for Non-DevelopersHL7 FHIR FoundationTopics for Non-Developers
HL7 FHIR FoundationTopics for Non-Developers
Peter Jordan
 
HIMSS Digital Healthcare Week 2013- The journey from HL7v2 to HL7 FHIR
HIMSS Digital Healthcare Week 2013- The journey from HL7v2 to HL7 FHIRHIMSS Digital Healthcare Week 2013- The journey from HL7v2 to HL7 FHIR
HIMSS Digital Healthcare Week 2013- The journey from HL7v2 to HL7 FHIR
Victor Chai
 
Rest APIs Training
Rest APIs TrainingRest APIs Training
Rest APIs Training
Shekhar Kumar
 
Hdfs
HdfsHdfs
www | HTTP | HTML - Tutorial
www | HTTP | HTML - Tutorialwww | HTTP | HTML - Tutorial
www | HTTP | HTML - Tutorial
MSA Technosoft
 
Http protocol
Http protocolHttp protocol
Http protocol
Arpita Naik
 
HDF Cloud: HDF5 at Scale
HDF Cloud: HDF5 at ScaleHDF Cloud: HDF5 at Scale
REST Api Tips and Tricks
REST Api Tips and TricksREST Api Tips and Tricks
REST Api Tips and Tricks
Maksym Bruner
 
ADV Slides: Trends in Streaming Analytics and Message-oriented Middleware
ADV Slides: Trends in Streaming Analytics and Message-oriented MiddlewareADV Slides: Trends in Streaming Analytics and Message-oriented Middleware
ADV Slides: Trends in Streaming Analytics and Message-oriented Middleware
DATAVERSITY
 
HL7 FHIR: Potential Uses in New Zealand
HL7 FHIR: Potential Uses in New ZealandHL7 FHIR: Potential Uses in New Zealand
HL7 FHIR: Potential Uses in New Zealand
Peter Jordan
 
FHIR for clinicians
FHIR for clinicians FHIR for clinicians
FHIR for clinicians
David Hay
 
Accessing HDF5 data in the cloud with HSDS
Accessing HDF5 data in the cloud with HSDSAccessing HDF5 data in the cloud with HSDS
Accessing HDF5 data in the cloud with HSDS
The HDF-EOS Tools and Information Center
 
ReSTfulAPIs
ReSTfulAPIsReSTfulAPIs
ReSTfulAPIs
Claudine Bruyns
 
APIsecure 2023 - FHIR API Security, Grahame Grieve (Health Intersections)
APIsecure 2023 - FHIR API Security, Grahame Grieve (Health Intersections)APIsecure 2023 - FHIR API Security, Grahame Grieve (Health Intersections)
APIsecure 2023 - FHIR API Security, Grahame Grieve (Health Intersections)
apidays
 
Linked Data Platform as a novel approach for Enterprise Application Integra...
Linked Data Platform as a novel approach for Enterprise Application Integra...Linked Data Platform as a novel approach for Enterprise Application Integra...
Linked Data Platform as a novel approach for Enterprise Application Integra...
Nandana Mihindukulasooriya
 
Whats new (grahame)
Whats new (grahame)Whats new (grahame)
Whats new (grahame)
DevDays
 
5 Tips to Optimize SharePoint While Preparing for Hybrid
5 Tips to Optimize SharePoint While Preparing for Hybrid5 Tips to Optimize SharePoint While Preparing for Hybrid
5 Tips to Optimize SharePoint While Preparing for Hybrid
Adam Levithan
 

Similar to FHIR for Architects and Developers - New Zealand Seminar, June 2014 (20)

FHIR - as a new currency of exchange in New Zealand
FHIR - as a new currency of exchange in New ZealandFHIR - as a new currency of exchange in New Zealand
FHIR - as a new currency of exchange in New Zealand
 
Fire and Ice - FHIR in New Zealand - David Hay
Fire and Ice - FHIR in New Zealand - David HayFire and Ice - FHIR in New Zealand - David Hay
Fire and Ice - FHIR in New Zealand - David Hay
 
HDFCloud Workshop: HDF5 in the Cloud
HDFCloud Workshop: HDF5 in the CloudHDFCloud Workshop: HDF5 in the Cloud
HDFCloud Workshop: HDF5 in the Cloud
 
HL7 FHIR FoundationTopics for Non-Developers
HL7 FHIR FoundationTopics for Non-DevelopersHL7 FHIR FoundationTopics for Non-Developers
HL7 FHIR FoundationTopics for Non-Developers
 
HIMSS Digital Healthcare Week 2013- The journey from HL7v2 to HL7 FHIR
HIMSS Digital Healthcare Week 2013- The journey from HL7v2 to HL7 FHIRHIMSS Digital Healthcare Week 2013- The journey from HL7v2 to HL7 FHIR
HIMSS Digital Healthcare Week 2013- The journey from HL7v2 to HL7 FHIR
 
Rest APIs Training
Rest APIs TrainingRest APIs Training
Rest APIs Training
 
Hdfs
HdfsHdfs
Hdfs
 
www | HTTP | HTML - Tutorial
www | HTTP | HTML - Tutorialwww | HTTP | HTML - Tutorial
www | HTTP | HTML - Tutorial
 
Http protocol
Http protocolHttp protocol
Http protocol
 
HDF Cloud: HDF5 at Scale
HDF Cloud: HDF5 at ScaleHDF Cloud: HDF5 at Scale
HDF Cloud: HDF5 at Scale
 
REST Api Tips and Tricks
REST Api Tips and TricksREST Api Tips and Tricks
REST Api Tips and Tricks
 
ADV Slides: Trends in Streaming Analytics and Message-oriented Middleware
ADV Slides: Trends in Streaming Analytics and Message-oriented MiddlewareADV Slides: Trends in Streaming Analytics and Message-oriented Middleware
ADV Slides: Trends in Streaming Analytics and Message-oriented Middleware
 
HL7 FHIR: Potential Uses in New Zealand
HL7 FHIR: Potential Uses in New ZealandHL7 FHIR: Potential Uses in New Zealand
HL7 FHIR: Potential Uses in New Zealand
 
FHIR for clinicians
FHIR for clinicians FHIR for clinicians
FHIR for clinicians
 
Accessing HDF5 data in the cloud with HSDS
Accessing HDF5 data in the cloud with HSDSAccessing HDF5 data in the cloud with HSDS
Accessing HDF5 data in the cloud with HSDS
 
ReSTfulAPIs
ReSTfulAPIsReSTfulAPIs
ReSTfulAPIs
 
APIsecure 2023 - FHIR API Security, Grahame Grieve (Health Intersections)
APIsecure 2023 - FHIR API Security, Grahame Grieve (Health Intersections)APIsecure 2023 - FHIR API Security, Grahame Grieve (Health Intersections)
APIsecure 2023 - FHIR API Security, Grahame Grieve (Health Intersections)
 
Linked Data Platform as a novel approach for Enterprise Application Integra...
Linked Data Platform as a novel approach for Enterprise Application Integra...Linked Data Platform as a novel approach for Enterprise Application Integra...
Linked Data Platform as a novel approach for Enterprise Application Integra...
 
Whats new (grahame)
Whats new (grahame)Whats new (grahame)
Whats new (grahame)
 
5 Tips to Optimize SharePoint While Preparing for Hybrid
5 Tips to Optimize SharePoint While Preparing for Hybrid5 Tips to Optimize SharePoint While Preparing for Hybrid
5 Tips to Optimize SharePoint While Preparing for Hybrid
 

More from David Hay

FHIR for implementers in New Zealand
FHIR for implementers in New ZealandFHIR for implementers in New Zealand
FHIR for implementers in New Zealand
David Hay
 
Christchurch presentation
Christchurch presentationChristchurch presentation
Christchurch presentation
David Hay
 
Payer extract connectathonupdate
Payer extract connectathonupdatePayer extract connectathonupdate
Payer extract connectathonupdate
David Hay
 
Genomics connectathon
Genomics connectathonGenomics connectathon
Genomics connectathon
David Hay
 
itx presentation: FHIR and the New Zealand EHR - deeper dive
itx presentation: FHIR and the New Zealand EHR - deeper diveitx presentation: FHIR and the New Zealand EHR - deeper dive
itx presentation: FHIR and the New Zealand EHR - deeper dive
David Hay
 
itx presentation: FHIR and the New Zealand EHR
itx presentation: FHIR and the New Zealand EHRitx presentation: FHIR and the New Zealand EHR
itx presentation: FHIR and the New Zealand EHR
David Hay
 
Fhir seminar hinz 2015
Fhir seminar hinz 2015Fhir seminar hinz 2015
Fhir seminar hinz 2015
David Hay
 
Archetypes and FHIR by Koray Atalag
Archetypes and FHIR by Koray AtalagArchetypes and FHIR by Koray Atalag
Archetypes and FHIR by Koray Atalag
David Hay
 
Ihic preso v2
Ihic preso v2Ihic preso v2
Ihic preso v2
David Hay
 

More from David Hay (9)

FHIR for implementers in New Zealand
FHIR for implementers in New ZealandFHIR for implementers in New Zealand
FHIR for implementers in New Zealand
 
Christchurch presentation
Christchurch presentationChristchurch presentation
Christchurch presentation
 
Payer extract connectathonupdate
Payer extract connectathonupdatePayer extract connectathonupdate
Payer extract connectathonupdate
 
Genomics connectathon
Genomics connectathonGenomics connectathon
Genomics connectathon
 
itx presentation: FHIR and the New Zealand EHR - deeper dive
itx presentation: FHIR and the New Zealand EHR - deeper diveitx presentation: FHIR and the New Zealand EHR - deeper dive
itx presentation: FHIR and the New Zealand EHR - deeper dive
 
itx presentation: FHIR and the New Zealand EHR
itx presentation: FHIR and the New Zealand EHRitx presentation: FHIR and the New Zealand EHR
itx presentation: FHIR and the New Zealand EHR
 
Fhir seminar hinz 2015
Fhir seminar hinz 2015Fhir seminar hinz 2015
Fhir seminar hinz 2015
 
Archetypes and FHIR by Koray Atalag
Archetypes and FHIR by Koray AtalagArchetypes and FHIR by Koray Atalag
Archetypes and FHIR by Koray Atalag
 
Ihic preso v2
Ihic preso v2Ihic preso v2
Ihic preso v2
 

Recently uploaded

How dental support group work...........
How dental support group work...........How dental support group work...........
How dental support group work...........
AvilasDentalGroup
 
arm balance asana - Comprehensive understanding of arm balancing asana
arm balance asana - Comprehensive understanding of arm balancing asanaarm balance asana - Comprehensive understanding of arm balancing asana
arm balance asana - Comprehensive understanding of arm balancing asana
Karuna Yoga Vidya Peetham
 
Girls Call Hyderabad 000XX00000 Provide Best And Top Girl Service And No1 in ...
Girls Call Hyderabad 000XX00000 Provide Best And Top Girl Service And No1 in ...Girls Call Hyderabad 000XX00000 Provide Best And Top Girl Service And No1 in ...
Girls Call Hyderabad 000XX00000 Provide Best And Top Girl Service And No1 in ...
pinkichadda23 #v08
 
3.INFLAMMATION Of Nursing Second Students
3.INFLAMMATION Of Nursing Second Students3.INFLAMMATION Of Nursing Second Students
3.INFLAMMATION Of Nursing Second Students
tamiratdebebe303
 
Girls Call Thane 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Thane 000XX00000 Provide Best And Top Girl Service And No1 in CityGirls Call Thane 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Thane 000XX00000 Provide Best And Top Girl Service And No1 in City
snehamittal#G05
 
High Class Girls Call Mumbai 9910780858 Provide Best And Top Girl Service And...
High Class Girls Call Mumbai 9910780858 Provide Best And Top Girl Service And...High Class Girls Call Mumbai 9910780858 Provide Best And Top Girl Service And...
High Class Girls Call Mumbai 9910780858 Provide Best And Top Girl Service And...
jealousviolet
 
New Girls Call Navi Mumbai 9930245274 Unlimited Short Providing Girls Service...
New Girls Call Navi Mumbai 9930245274 Unlimited Short Providing Girls Service...New Girls Call Navi Mumbai 9930245274 Unlimited Short Providing Girls Service...
New Girls Call Navi Mumbai 9930245274 Unlimited Short Providing Girls Service...
revolutionary575
 
Inflammation.pptx (type , cellular event of infllmation .etc)
Inflammation.pptx (type , cellular event of infllmation .etc)Inflammation.pptx (type , cellular event of infllmation .etc)
Inflammation.pptx (type , cellular event of infllmation .etc)
AviralSharma91
 
Girls Call Delhi 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Delhi 000XX00000 Provide Best And Top Girl Service And No1 in CityGirls Call Delhi 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Delhi 000XX00000 Provide Best And Top Girl Service And No1 in City
snehamittal#G05
 
Top 9 Challenges faced by Sterile Processing Technicians.pptx
Top 9 Challenges faced by Sterile Processing Technicians.pptxTop 9 Challenges faced by Sterile Processing Technicians.pptx
Top 9 Challenges faced by Sterile Processing Technicians.pptx
orionallied123
 
Compartment syndrome, meaning , types, causes , nursing management , murugesh...
Compartment syndrome, meaning , types, causes , nursing management , murugesh...Compartment syndrome, meaning , types, causes , nursing management , murugesh...
Compartment syndrome, meaning , types, causes , nursing management , murugesh...
MurugeshHJ1
 
Girls Call Delhi 9873940964 Provide Best And Top Girl Service And No1 in City
Girls Call Delhi 9873940964 Provide Best And Top Girl Service And No1 in CityGirls Call Delhi 9873940964 Provide Best And Top Girl Service And No1 in City
Girls Call Delhi 9873940964 Provide Best And Top Girl Service And No1 in City
elbertablack
 
Ihuman Case Study Help-ihuman case study modules help.pdf
Ihuman Case Study Help-ihuman case study modules help.pdfIhuman Case Study Help-ihuman case study modules help.pdf
Ihuman Case Study Help-ihuman case study modules help.pdf
Reliable Assignments Help
 
kneeling asana - Comprehensive understanding of kneeling asana
kneeling asana - Comprehensive understanding of kneeling asanakneeling asana - Comprehensive understanding of kneeling asana
kneeling asana - Comprehensive understanding of kneeling asana
Karuna Yoga Vidya Peetham
 
Visual Processing, Visual Perception & Visual-Motor Deficit.pdf
Visual Processing, Visual Perception & Visual-Motor Deficit.pdfVisual Processing, Visual Perception & Visual-Motor Deficit.pdf
Visual Processing, Visual Perception & Visual-Motor Deficit.pdf
Occupational Therapist
 
فورمة اسينمنت فاضية لطلاب القمة كورس مساعد طبيب الاسنان 5 د حاتم البيطار القم...
فورمة اسينمنت فاضية لطلاب القمة كورس مساعد طبيب الاسنان 5 د حاتم البيطار القم...فورمة اسينمنت فاضية لطلاب القمة كورس مساعد طبيب الاسنان 5 د حاتم البيطار القم...
فورمة اسينمنت فاضية لطلاب القمة كورس مساعد طبيب الاسنان 5 د حاتم البيطار القم...
د حاتم البيطار
 
Female Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Serv...
Female Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Serv...Female Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Serv...
Female Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Serv...
bellared2
 
chapter 1- changing trends in physical education.pptx
chapter 1- changing trends in physical education.pptxchapter 1- changing trends in physical education.pptx
chapter 1- changing trends in physical education.pptx
divijsinghrenu10
 
Girls Call ServiCe Chennai X00XXX00XX Tanisha Best High Class Chennai Available
Girls Call ServiCe Chennai X00XXX00XX Tanisha Best High Class Chennai AvailableGirls Call ServiCe Chennai X00XXX00XX Tanisha Best High Class Chennai Available
Girls Call ServiCe Chennai X00XXX00XX Tanisha Best High Class Chennai Available
shamrisumri
 
Bronchiectasis and Physiotherapy Management
Bronchiectasis and Physiotherapy ManagementBronchiectasis and Physiotherapy Management
Bronchiectasis and Physiotherapy Management
abdulazeezvpadikkal
 

Recently uploaded (20)

How dental support group work...........
How dental support group work...........How dental support group work...........
How dental support group work...........
 
arm balance asana - Comprehensive understanding of arm balancing asana
arm balance asana - Comprehensive understanding of arm balancing asanaarm balance asana - Comprehensive understanding of arm balancing asana
arm balance asana - Comprehensive understanding of arm balancing asana
 
Girls Call Hyderabad 000XX00000 Provide Best And Top Girl Service And No1 in ...
Girls Call Hyderabad 000XX00000 Provide Best And Top Girl Service And No1 in ...Girls Call Hyderabad 000XX00000 Provide Best And Top Girl Service And No1 in ...
Girls Call Hyderabad 000XX00000 Provide Best And Top Girl Service And No1 in ...
 
3.INFLAMMATION Of Nursing Second Students
3.INFLAMMATION Of Nursing Second Students3.INFLAMMATION Of Nursing Second Students
3.INFLAMMATION Of Nursing Second Students
 
Girls Call Thane 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Thane 000XX00000 Provide Best And Top Girl Service And No1 in CityGirls Call Thane 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Thane 000XX00000 Provide Best And Top Girl Service And No1 in City
 
High Class Girls Call Mumbai 9910780858 Provide Best And Top Girl Service And...
High Class Girls Call Mumbai 9910780858 Provide Best And Top Girl Service And...High Class Girls Call Mumbai 9910780858 Provide Best And Top Girl Service And...
High Class Girls Call Mumbai 9910780858 Provide Best And Top Girl Service And...
 
New Girls Call Navi Mumbai 9930245274 Unlimited Short Providing Girls Service...
New Girls Call Navi Mumbai 9930245274 Unlimited Short Providing Girls Service...New Girls Call Navi Mumbai 9930245274 Unlimited Short Providing Girls Service...
New Girls Call Navi Mumbai 9930245274 Unlimited Short Providing Girls Service...
 
Inflammation.pptx (type , cellular event of infllmation .etc)
Inflammation.pptx (type , cellular event of infllmation .etc)Inflammation.pptx (type , cellular event of infllmation .etc)
Inflammation.pptx (type , cellular event of infllmation .etc)
 
Girls Call Delhi 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Delhi 000XX00000 Provide Best And Top Girl Service And No1 in CityGirls Call Delhi 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Delhi 000XX00000 Provide Best And Top Girl Service And No1 in City
 
Top 9 Challenges faced by Sterile Processing Technicians.pptx
Top 9 Challenges faced by Sterile Processing Technicians.pptxTop 9 Challenges faced by Sterile Processing Technicians.pptx
Top 9 Challenges faced by Sterile Processing Technicians.pptx
 
Compartment syndrome, meaning , types, causes , nursing management , murugesh...
Compartment syndrome, meaning , types, causes , nursing management , murugesh...Compartment syndrome, meaning , types, causes , nursing management , murugesh...
Compartment syndrome, meaning , types, causes , nursing management , murugesh...
 
Girls Call Delhi 9873940964 Provide Best And Top Girl Service And No1 in City
Girls Call Delhi 9873940964 Provide Best And Top Girl Service And No1 in CityGirls Call Delhi 9873940964 Provide Best And Top Girl Service And No1 in City
Girls Call Delhi 9873940964 Provide Best And Top Girl Service And No1 in City
 
Ihuman Case Study Help-ihuman case study modules help.pdf
Ihuman Case Study Help-ihuman case study modules help.pdfIhuman Case Study Help-ihuman case study modules help.pdf
Ihuman Case Study Help-ihuman case study modules help.pdf
 
kneeling asana - Comprehensive understanding of kneeling asana
kneeling asana - Comprehensive understanding of kneeling asanakneeling asana - Comprehensive understanding of kneeling asana
kneeling asana - Comprehensive understanding of kneeling asana
 
Visual Processing, Visual Perception & Visual-Motor Deficit.pdf
Visual Processing, Visual Perception & Visual-Motor Deficit.pdfVisual Processing, Visual Perception & Visual-Motor Deficit.pdf
Visual Processing, Visual Perception & Visual-Motor Deficit.pdf
 
فورمة اسينمنت فاضية لطلاب القمة كورس مساعد طبيب الاسنان 5 د حاتم البيطار القم...
فورمة اسينمنت فاضية لطلاب القمة كورس مساعد طبيب الاسنان 5 د حاتم البيطار القم...فورمة اسينمنت فاضية لطلاب القمة كورس مساعد طبيب الاسنان 5 د حاتم البيطار القم...
فورمة اسينمنت فاضية لطلاب القمة كورس مساعد طبيب الاسنان 5 د حاتم البيطار القم...
 
Female Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Serv...
Female Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Serv...Female Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Serv...
Female Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Serv...
 
chapter 1- changing trends in physical education.pptx
chapter 1- changing trends in physical education.pptxchapter 1- changing trends in physical education.pptx
chapter 1- changing trends in physical education.pptx
 
Girls Call ServiCe Chennai X00XXX00XX Tanisha Best High Class Chennai Available
Girls Call ServiCe Chennai X00XXX00XX Tanisha Best High Class Chennai AvailableGirls Call ServiCe Chennai X00XXX00XX Tanisha Best High Class Chennai Available
Girls Call ServiCe Chennai X00XXX00XX Tanisha Best High Class Chennai Available
 
Bronchiectasis and Physiotherapy Management
Bronchiectasis and Physiotherapy ManagementBronchiectasis and Physiotherapy Management
Bronchiectasis and Physiotherapy Management
 

FHIR for Architects and Developers - New Zealand Seminar, June 2014

  • 1. FHIR for Architects and Developers Acknowledgements • Lloyd McKenzie • Ewout Kramer • Grahame Grieve Agenda • Architectures • Paradigms • Resources • Bundles • Profiles & Extensions • Server Notes • Workflow • Security • Tools and Help • Next steps in New Zealand
  • 2. Page 2 • HL7 New Zealand The Spec: Hl7.org/fhir 2
  • 4. Page 4 • HL7 New Zealand Architectures • FHIR makes no assumptions about the architectural design of systems • You can use it for – Light or heavy clients – Central server or peer-to-peer sharing – Push or pull – Query or publish/subscribe – Loosely coupled or tightly coupled environments  With history tracking (versions) or without 4
  • 5. Page 5 • HL7 New Zealand Some possibilities 5 FHIR Broker v3 v2 PHR FHIR App Comm. Interface DB FHIR
  • 6. Page 6 • HL7 New Zealand Repository model Vendor Neutral Repository FHIR HIS GP PACS SystemX Gateway FHIR FHIRFHIRFHIR
  • 7. Page 7 • HL7 New Zealand Beyond exchange 7 v3 v2 Other X12 Broker v3 v2 FHIR Repository Decision Support FHIR FHIR Other
  • 8. Page 8 • HL7 New Zealand Bottom Line • FHIR is a set of tools – Defined resources – Extensibility mechanism – Versioning – Multi-paradigm – Set of standard interfaces – Support for complex services • Primary purpose is interoperable data exchange • However, it can be leveraged in many ways – Many we haven’t even thought of yet . . . 8
  • 10. Page 10 • HL7 New Zealand Paradigms • FHIR supports 4 interoperability paradigms 10 REST Documents Messages Services What should you use when?
  • 12. Page 12 • HL7 New Zealand REST • Simple, out-of-the-box interoperability • Leverage HTTP: GET, POST, etc. • Pre-defined operations – Create, Read, Update, Delete – Also: History, Read Version, Search, Updates, Validate, Conformance & Batch (Transaction) • HTTP Headers for various options – Like resource format or location • Response codes to indicate outcome – OperationOutcome Resource • Works best in environments where control resides on client side and trust relationship exists 12 Rest
  • 13. Page 13 • HL7 New Zealand Creating & Updating • POST vs PUT • Headers – Request • Content-type • Location (for version aware) – Response • Content-type • Others... • Status messages – Standard HTTP • OperationOutcome • Version aware updates
  • 14. Page 14 • HL7 New Zealand Querying by REST • Base queries – Simple GET against a resource type – GET [base]/Patient?name=eve • Defined rules for query parameters • More complex – _include – Tags • Queries across reference – Eg conditions for a patient – GET [base]/Condition?subject=84238862 – Chained queries • Compartments – Syntactic sugar – GET [base]/Patient/84238862/Condition
  • 15. Page 15 • HL7 New Zealand Synchronizing • History of all resources on server – GET [base]/fhir/_history • History of all patient resources on server – GET [base]/Patient/_history • History of specific patient on server – GET [base]/Patient/1/_history • A history of all changes: inserts, updates and deletions, ordered by newest first • Limit with _since and _count
  • 16. Page 16 • HL7 New Zealand What’s a ‘deleted’ Resource? • Delete using DELETE verb • Trying read operations will return in a 410 (Gone) result in stead of 404 (Not Found) • The resource will not be returned by the search operation. • You can “undelete” by doing an update (PUT) with fresh content • Just a “marker” in a resource’s history
  • 17. Page 17 • HL7 New Zealand Version history - deletions 33, v12 – 2012-12-04 33, v13 – 2012-12-05 33, v14 – 2012-12-08 /server.org/fhir/Patient/33/_history/12 /server.org/fhir/Patient/33/_history/14 /server.org/fhir/Patient/33/_history/13 /server.org/fhir/Patient/33/_history/15 /server.org/fhir/Patient/33 33, v15 – 2012-12-09 33, v16 – 2012-12-10 DELETION /server.org/fhir/Patient/33/_history/16
  • 18. Page 18 • HL7 New Zealand Version history - revival 33, v13 – 2012-12-05 33, v14 – 2012-12-08 /server.org/fhir/Patient/33/_history/14 /server.org/fhir/Patient/33/_history/13 /server.org/fhir/Patient/33/_history/15 /server.org/fhir/Patient/33 33, v15 – 2012-12-09 33, v16 – 2012-12-10 /server.org/fhir/Patient/33/_history/16 33, v17 – 2012-12-11 /server.org/fhir/Patient/33/_history/17
  • 19. Page 19 • HL7 New Zealand Batch • POST a bundle to server root • Processed as a transaction – All succeed, or all fail • All operations supported • Different to /message endpoint – /message allows custom server processing – Batch is a sequence processed as a transaction
  • 21. Page 21 • HL7 New Zealand Test Servers • Servers – At least 4 to choose from – http://spark.furore.com/fhir/Patient/nz100 – http://fhir.healthintersections.com.au/open/Patient/100 – fhir.orionhealth.com/blaze/fhir/Patient – https://his-medicomp-gateway.orionhealth.com/blaze/fhir/metadata • Tools – XML Editor (Oxygen) – REST Client (POSTMan) 21 Script • Search patient on name • GET single patient from list • XML & JSON • Update and PUT back • repeat REST Search • Show error
  • 22. Page 22 • HL7 New Zealand When to use REST? • Want low coupling between systems – In theory, very little up-front negotiation required • Small, light-weight exchanges • Focus is CRUD operations – Also for publish/subscribe • Client-driven client-server orchestration • Server endpoint has fixed location • Well-suited for Mobile, PHR, Registries 22 Rest
  • 23. Page 23 • HL7 New Zealand When to avoid REST? • Complex or server-driven orchestration – Order of operations matters (e.g. complex decision support) • Unit of work != resource – “Transaction” may be an option • Lack of trust in the client for audit, etc. 23 Rest
  • 25. Page 25 • HL7 New Zealand Documents • Similar to CDA • Collection of resources bound together – Root is a “Composition” resource – Just like CDA header • Sent as an ATOM feed – Usually stored as binary blob – Can be separate resource with Composition as ‘entry’ point • One context – Not propagated • Can be signed, authenticated, etc. • Working on conversion between FHIR Doc & CDA 25 Documents
  • 26. Page 26 • HL7 New Zealand Documents – are bundles 26 Observation Resource Composition Resource Section Section Device Resource Patient Resource Prescription Resource <feed> <entry> <Composition /> </entry> <entry> <Observation /> </entry> <entry> <Device /> </entry> <entry> <Prescription /> </entry> <entry> <Patient /> </entry> </feed> AttesterMetadata
  • 27. Page 27 • HL7 New Zealand The Composition resource 27
  • 28. Page 28 • HL7 New Zealand Document Management • The DocumentReference resource – Enables ‘XDS-like’ services • The ‘registry’ is just a FHIR server – Same query capabilities • Point to document – Any document (FHIR Doc, CDA, PDF etc).
  • 29. Page 30 • HL7 New Zealand XDS FHIR Style (MDS)
  • 30. Page 31 • HL7 New Zealand When to use Documents? • No different to CDA • Focus is on persistence • No workflow involved – other than post/retrieve document • Need tight rules over authenticated content • Want to communicate multiple resources with control over how data is presented • Data spans multiple resources 31 Documents
  • 31. Page 32 • HL7 New Zealand When to avoid Documents? • Need for workflow – Request/response, decision support • Data is dynamic – I.e. want view of data now, not at time of authorship – Multiple contributors over time • Resources need to be accessed/manipulated independently 32 Documents
  • 33. Page 34 • HL7 New Zealand Messages • Similar to v2 and v3 messaging • Also a collection of resources as an ATOM feed • Allows request/response behavior with bundles for both request and response – /message endpoint on REST server • Event-driven – E.g. Send lab order, get back result • Can be asynchronous 34 Messages
  • 34. Page 35 • HL7 New Zealand Messages – are bundles 35 Observation Resource MessageHeader source destination Device Resource Patient Resource <feed> <entry> <MessageHeader /> </entry> <entry> <Observation /> </entry> <entry> <Patient /> </entry> <entry> <Device /> </entry> </feed> event
  • 35. Page 36 • HL7 New Zealand MessageHeader Resource 36 Resource used in both request & response
  • 36. Page 37 • HL7 New Zealand FHIR messages • No storage of the “Message” resource implied. Might be used in a router, converted to v2, etc. • The server can process them based on the event code and return the response as another message (again a bundle). 37
  • 37. Page 38 • HL7 New Zealand Communicating messages • Message Exchange Pattern • Synchronous in standard • Async supported • Reliability • Transport • REST supported but, you can send FHIR Messages over mail, MLLP, TCP, IPoAC (or Healthlink!) • FHIR defines an HTTP end-point for messages • http://server.org/fhir/Mailbox • Response comes back in the acknowledgment payload 38
  • 38. Page 39 • HL7 New Zealand Revisiting the Immunization Forecast TCH ForecasterFHIR ServerFHIR Client TCH Forecaster with FHIR Message InterfaceFHIR Client
  • 39. Page 40 • HL7 New Zealand When to use Messaging? • Request/response workflow • Need to drive behaviors more complex than CRUD on a single resource – E.g. merge, complex queries • Need for asynchronous communications • Need to communicate information about many resources but want to minimize exchanges • No “identity” for many resources 40 Messages
  • 40. Page 41 • HL7 New Zealand When to avoid Messaging? • Precise control required on how data gets persisted/displayed to humans • Need for lightweight communications • Want to avoid pre-negotiations on behavior 41 Messages
  • 42. Page 43 • HL7 New Zealand Service Oriented Architecture (SOA) • Do whatever you like – (based on SOA principles) – Ultra complex workflows – Ultra simple workflows – Individual resources or collections (in Atom or other formats) – Use HTTP or use something else – Only constraint is that you’re passing around FHIR resources in some shape or manner 43 Services
  • 43. Page 44 • HL7 New Zealand When to use Services? • All previous paradigms are a type of services interface • Use a custom service when capabilities of other paradigms don’t fit requirement – Operations other than CRUD on a resource (e.g. decision support) – Workflow more complex than simple request/response – Need to mix document persistence with behavior 44 Services
  • 44. Page 45 • HL7 New Zealand When not to use services? • When something else will do the job as well – I.e. Don’t define a custom service for something that already naturally is handled by REST, messaging, etc. 45 Services
  • 45. Page 46 • HL7 New Zealand Paradigm guidance • No absolutes – Consider a “when to avoid” as a note of caution – Capabilities/architecture of legacy will often drive approach, particularly initially • E.g. If v2 back end, messaging – Architectures will be driven by legacy requirements, architectural preferences, enterprise architecture commitments, etc. 46
  • 46. Page 47 • HL7 New Zealand Combining paradigms • No requirement for a system to only support one paradigm – E.g. hospital may be primarily messaging, but use documents for discharge summaries and reports and expose registries and appointments via REST with a few custom services for decision support or specialized workflow • Data (generally) shared easily across paradigm boundaries • Caveats: – If updates come in via document, message or service, RESTful version id still needs to increment – Documents should typically be persisted whole, not reconstituted from parts • Ensures signature validity – Legacy messaging systems may not provide the metadata to easily expose or manipulate discrete resources via REST 47
  • 48. Page 49 • HL7 New Zealand Resource Definition • Every resource definition has: – Scope and use – ‘UML’ representtaion – XML representation – Bindings – Constraints – Resource specific notes – Examples • And computable – XSD Schema – schematron
  • 49. Page 50 • HL7 New Zealand XML & JSON <Patient xmlns="http://hl7.org/fhir"> <text> <status value="generated" /> <div xmlns="http://www.w3.org/1999/xhtml">Doe, John</div> </text> <identifier> <label value="NI" /> <system value="http://moh.govt.nz/fhir/patient/nhi" /> <value value="PRP1660" /> </identifier> <name> <use value="official" /> <family value="Garrett" /> <given value="Gordon" /> </name> </Patient> { "resourceType": "Patient", "text": { "status": "generated", "div": "<div xmlns="http://www.w3.org/1999/xhtml">Doe, John</div>" }, "identifier": [ { "label": "NI", "system": "http://moh.govt.nz/fhir/patient/nhi", "value": "PRP1660" } ], "name": [ { "use": "official", "family": [ "Garrett" ], "given": [ "Gordon" ] } ] }
  • 50. Page 51 • HL7 New Zealand Specify format using REST GET /fhir/Patient/1?_format=json HTTP/1.1 HTTP/1.1 200 OK Content-Type: application/json+fhir;charset=utf-8 Content-Length: 787 GET /fhir/Patient/1 HTTP/1.1 Accept: application/json+fhir HTTP/1.1 200 OK Content-Type: application/json+fhir;charset=utf-8 Content-Length: 787 Same for Create/Update
  • 51. Page 52 • HL7 New Zealand Resource metadata Patient MRN 22234 “Ewout Kramer” 30-11-1972 Amsterdam Metadata Resource Identities http://fhir.hl7.org/Patient/23E455A3B http://fhir.hl7.org/Patient/23E455A3B/_his Last updated 2013-12-23T23:33:01+01:00 http://hl7.org/fhir/tag/profile http://hl7.org/fhir/Profile/us-core http://hl7.org/fhir/tag http://example.org/fhir/Status#Test
  • 52. Page 54 • HL7 New Zealand Identity • 2 different ‘sorts’ of identity – ID identifies a resource on a server • Is metadata • Will change between servers – Identifier • Business identifier • Is an element in the resource
  • 53. Page 55 • HL7 New Zealand A Resource’s ID • In fact: an URL – http://server.org/fhir/Patient/1 endpoint resource type identifier Note: This URL resolves to the current version of a resource It’s also specific to a server
  • 54. Page 56 • HL7 New Zealand “Business” identifiers
  • 55. Page 58 • HL7 New Zealand Narrative
  • 56. Page 59 • HL7 New Zealand Tags • Contain metadata about resources – Beyond ID, version & date • Used for different purposes: – Compliance to Profile – Security – e.g. sensitivity of resource – Indicate Document/Message – User defined • Transported in different ways: – REST – as an HTTP header – In a bundle (document, message, transaction) - in the feed.category element
  • 57. Page 60 • HL7 New Zealand Versioning • Most recent version – http://server.org/fhir/Patient/1 – Returns single resource • All versions – http://server.org/fhir/Patient/1/_history – Returns bundle of versions • Specific version – http://server.org/fhir/Patient/1/_history/_1 – Returns single resource • Version support is optional • Works at instance and type level
  • 58. Page 61 • HL7 New Zealand Resource Reference Example: part of DiagnosticReport
  • 59. Page 62 • HL7 New Zealand Coded values: the ValueSet resource • Most coded elements have a set of possible values – Large or small – Static • (change slowly) • Can use ValueSet resource to define set of possibilities – A “true” FHIR ValueSet resource (may be version specific) • Can contain: – References to a terminology (like SNOMED) – A list of specific codes • Examples – International examples • All the HL7 version 2 ‘tables’ – NZ Examples • Iwi & Hapu • DHB’s 62
  • 60. Page 63 • HL7 New Zealand Example of ValueSet <?xml version="1.0" encoding="UTF-8"?> <ValueSet xmlns="http://hl7.org/fhir"> <text> <status value="additional"/> <div xmlns="http://www.w3.org/1999/xhtml">The value set for confidentiality codes in the elbonian docume project. The codes are defined directly by the valueset, rather than references to an external terminology</d </text> <name value="ConfidentialityOptions"/> <description value="ConfidentialityOptions"/> <status value="draft"/> <!-- Define the options in the resource rather than an external terminology--> <define> <system value="http://fhir.moh.elbonia.com/confidentiality"/> <concept> <code value='N'/> <display value="Normal"/> <definition value="That the document is of normal confidentiality "/> </concept> <concept> <code value='H'/> <display value="High"/> <definition value=”That the document is Highly confidential - eg Mental health "/> </concept> </define> </ValueSet>
  • 61. Page 64 • HL7 New Zealand Contained resources • When the contained resource has no separate identity • Has quite a few limitations • Use sparingly – Bundle always better if possible <Composition xmlns="http://hl7.org/fhir"> <extension>...</extension> <text>...</text> <contained> <Organization id="org1"> <!– other data --> </Organization> </contained> <information> <!-- other attributes --> <custodian> <reference value="#org1" /> </custodian> <!-- other attributes --> <information> </Document>
  • 62. Bundles in more detail
  • 63. Page 66 • HL7 New Zealand Review • Atom as the bundling mechanism – Query results – Document – Message • Request & Response – Batch/Transactions • XML or JSON – Conversion routines available – (Can’t use ordinary ones) • Use tags to identify Documents & Messages – First resource significant
  • 64. Page 67 • HL7 New Zealand
  • 65. Page 68 • HL7 New Zealand Resource Entry Version-specific id Resource id Last modified Resource content Human-readable form, just like Resource.text Tags
  • 66. Page 69 • HL7 New Zealand Bundle as a serialized Object Graph
  • 68. Page 71 • HL7 New Zealand The need for Profiles • Many different contexts in healthcare, but a single set of Resources – A desire to keep the resources manageable – Most elements in base resources optional • Need to be able to: – Describe restrictions based on use and context – Support elements not in the core resource • Allow for these usage statements to: – Authored in a structured manner – Published in a repository – Discoverable at Design and Run-time – Used as the basis for validation, code, report and UI generation. 71
  • 69. Page 72 • HL7 New Zealand Profiling a resource. For example... 72 Require that the identifier uses the NHI – and is required Limit names to just 1 (instead of 0..*) Limit maritalStatus to another set of codes that extends the one from HL7 international Add an extension to support “Iwi” Note: hardly any mandatory elements in the
  • 70. Page 73 • HL7 New Zealand Capabilities of Profiles • Descriptive – Information about the Profile (what, why, who) • Extending a resource – Adding new elements – Same capabilities/datatypes as existing ones • Constraining a resource – Specifying datatypes for an element – Modifying datatypes (eg translations) – Defining terminology bindings – Specifying multiplicity (eg make an element required) – Further refining repeating values (‘Slicing’) • Example of Composition.section (Document) – Cannot specify default values for resource instances • Everything explicit in an instance
  • 71. Page 74 • HL7 New Zealand Structured & published • A Profile is just a “normal” Resource • Any FHIR server could serve Profiles (just like Patients, Observations, etc…) • So, any FHIR server is a profile repository! • A profile is simply referred to by its URI: – Like any other resource • e.g. http://hl7.org/fhir/Profile/iso-21090 – Extensions in an ‘instance’ of a resource refer to the profile that defined them using the URI – Need to think about re-usability when designing profiles 74
  • 72. Page 75 • HL7 New Zealand Who publishes a Profile? http://www.hl7.org/fhir/Profile/iso -21090 http://www.hl7org.nz/fhir/Profile/ patient http://www.health4all.org/fhir/Pro file/
  • 73. Page 76 • HL7 New Zealand Using profiles • If we are a server then a client can read our conformance resource, which will list the profiles we support, and provide a link to them. – Conformance also has other functions like specifying supported resources, operations on those resources & interoperability paradigms • If we are a client, we can tell a server that we conform to a profile using a tag (the server will probably still check). – We could also ask a server just to validate – Could set up ‘distributed’ validation with (eg) National Validation servers used by local/regional servers • If we receive a resource with an extension we don’t recognize, it will point to the profile in which it is described so we can decide what to do with it. – Note that a single resource can reference different profiles 76
  • 74. Page 77 • HL7 New Zealand What’s in a profile, and its relationships? 77 Descriptive Identifier Name, Version Publisher Description, Code Status Date (of publication) Resource and Datatype Constraints Extension Definition Conformance (server) Resource (via Tag) ValueSet ValueSet Extension in Resource Tag
  • 75. Page 78 • HL7 New Zealand Scale / design • Make a profile with just extensions • Make a profile with just 1 resource + extensions on that resource • Make a profile with all (say national) resources + extensions. 78
  • 76. Page 79 • HL7 New Zealand Profile Descriptive information • To describe the purpose of the Profile • To help with location • Details – Identifier: Universally unique identifier, assigned by author value=“urn:hl7.org:extensions:iso-21090“ or “2.16.840.1.113883.10.20.2.1” – Version: Version of the profile, manually maintained by author. Suggested format: a timestamp (e.g. 2013-01-01T12:34:45) – Name: Free natural text name (e.g. “Extensions to support Orion Medications”) – Publisher: organization or individual responsible for publishing. Should be populated (e.g. “FHIR Project Team“) – Telecom: one or more contact points of the publisher (telephone, email, website etc) – Description: longer description of the contents of the profile – Code: one or more coded descriptions to help with finding the profile – Status (fixed choice of draft, active, retired) + experimental Y/N – Requirements: scope & usage (the “need” or “why” of the profile) – Date (of publication), e.g. “2013-07-07" 79
  • 77. Page 80 • HL7 New Zealand Constraining Structures (elements) • Defining terminology bindings – ValueSet is useful • Specify element datatypes • Further refining repeating values (‘Slicing’) • Specifying multiplicity From the spec Possibilities
  • 78. Page 81 • HL7 New Zealand Profile example Medication.code with a defined valueset
  • 79. Page 82 • HL7 New Zealand Profile Example • MedicationPrescription.asNeeded required, and must be boolean
  • 80. Page 83 • HL7 New Zealand Slicing • Constraining an element with 0..* , 1..* • FHIR Document as an example • Composition resource is the CDA Header equivalent – Composition.section is 0..* – A CCDA equivalent profile might specify the sections allowed • Different document types would have a profile
  • 82. Page 85 • HL7 New Zealand Extensions • Resources design for the 80% - Allow easy extension for the remaining 20% of elements • Note - You’re not extending a resource per se, but you specify its characteristics and where an extension may occur: – A specific element within a resource – A specific element within a datatype – All elements referencing a datatype – All elements mapping to a specific mapping target – An extension
  • 83. Page 86 • HL7 New Zealand Extensions • In FHIR, extensions are “normal” – Consequence of the 80% rule – keep the simple stuff simple – Extensions can exist anywhere • Yes, even inside boolean or date – Conformant systems can’t reject instances just because they contain unrecognized extensions – They could: • Display them – Should be in resource narrative • Store as a ‘Blob’ • Make a conscious decision to ignore (unless ModifierExtension) – (Could lookup profile) 86
  • 84. Page 87 • HL7 New Zealand Extension definition 87 Note: multiple contexts!
  • 85. Page 88 • HL7 New Zealand An Extension in a resource 88
  • 86. Page 89 • HL7 New Zealand Extending a multiple birth Key = location of formal definit Value = value according to definition
  • 87. Page 90 • HL7 New Zealand Modifier Extensions • Also a core part of FHIR – Needed because some extensions can’t be safely ignored – Can’t compute on an element containing an unrecognized modifier extension. However, can: • Reject instance • Just display narrative • Retrieve definition & seek human review 90
  • 88. Page 91 • HL7 New Zealand Modifier Extension decisions • When should you introduce them? – modifierExtension breaks interoperability so: • If you can accomplish your objective without one, do that – Consider a new resource or Other – Could requirement be met by an element that doesn’t change other element interpretations? – Best used when already part of existing practice, but in too narrow an area to justify being part of core 91
  • 89. Page 92 • HL7 New Zealand ‘Other’ resource • When there’s no way to extend an existing one • Has: – Identifier – Code – Subject – Author – Created • Rest is extensions • Should discuss with community first
  • 90. Page 93 • HL7 New Zealand Designing a Profile • Define Use Case • Choose resources – ‘Other’ if you have to • Constrain base elements – Remove – Make required – Define ValueSets and bindings • Define extensions – Try to re-use existing if possible – Note ‘hierarchy’ of extensions: • HL7 • National • Local • Build profile • Publish
  • 91. Page 94 • HL7 New Zealand The need for Governance • Profiles & extensions allow a user to customize their use of FHIR • HL7 is establishing publically available registries – For reference purposes • With great power...
  • 92. Page 95 • HL7 New Zealand Profile editors • Forge (FHIR.furore.com/forge)
  • 94. Page 97 • HL7 New Zealand Overview of a server 97 HTTP / REST interface Encoding/decoding, param validation, syntax validation Fhir Service Indexer / Search Storage Implement service operations as described in spec
  • 95. Page 98 • HL7 New Zealand From wire to store Storage Fhir Service REST interface JSON/XML POCO/POJ O DBMS O-R Map FHIR Parser 98 JSON/XML POCO/POJ O Serialize FHIR Parser NoSql (Xml/Json) JSON/XML POCO/POJ O DBMS Serialize FHIR Parser
  • 96. Page 99 • HL7 New Zealand Conformance resource • Allows a server to indicate: – Metadata about the server – The resources they support • The queries against those resources – The paradigms they support • REST, messaging, services – Specific (custom) queries – The profiles it supports • Is a normal resource – Supports discoverability (think UDDI for SOAP)
  • 97. Page 100 • HL7 New Zealand Conformance • Which FHIR version? • Which resources? • Which paradigms ? • What search operations? • What formats? • What profiles? • Is this a test server? • Who can I contact? • Do you support History? • Do you support JSON/XML? • Is a normal resource • Supports discoverability (think UDDI for SOAP)
  • 98. Page 101 • HL7 New Zealand Operation Outcome • When something goes wrong….return the OperationOutcome Resource!
  • 99. Page 102 • HL7 New Zealand Special endpoints • Binary – Store/retrieve a blob. – No query • Document – Works at ‘document’ level – Query on composition • Mailbox – Processing endpoint – Exact actions depending on Trading Partner Agreement • Note MessageHeader properties – eg event, reason
  • 101. Page 104 • HL7 New Zealand Workflow • Resource describe ‘things’ • Workflow says what to do with those things • Eg – ePresciption – Lab order – Referral • Order resources – Order – OrderResponse • Combination of Order(for workflow) and specific resource – Eg Order + MedicationPrescription
  • 102. Page 105 • HL7 New Zealand Referrals workflow 105
  • 103. Security and Privacy (Coming to the end…)
  • 104. Page 107 • HL7 New Zealand Overview • Signatures – On bundles • Tags used to ‘annotate’ resources – Eg private resource, ‘Special Patient’ – Application applies policy • Resources are atomic level • Some ‘security-related’ resources – SecurityEvent – Provenance • Philosophically FHIR delegates security to infrastructure – Others do that better – But does have comments
  • 105. Page 108 • HL7 New Zealand Wrapping Up: Tools for Developers • Specification – The full specification (included build tools) can be downloaded from the CVS at: http://gforge.hl7.org/gf/project/fhir • (Free to download, need account to update) • Examples • Validation files – XSD, Schematron • Test Servers – Open source • Reference Implementations – Java, .net, Objective-C, javascript – Open source – Reference Implementations from www.hl7.org/fhir • Tooling – XML/JSON editor – REST client 108
  • 106. Page 109 • HL7 New Zealand Further Information & Help • Information: – Specification: www.hl7.org/fhir • Fully hyper-linked • Includes many sample files and links to codesets & terminologies – Wiki pages: http://wiki.hl7.org/index.php?title=FHIR – HL7 Lists server: from HL7.org – Blogs (listed on spec) • Assistance – ‘Stack Overflow’ – tag hl7-FHIR – Skpe conversations (email me – david.hay@orionhealth.com to be included)
  • 107. Whew! Next Steps in New Zealand? A group discussion

Editor's Notes

  1. Published as HTML Published using validation process that performs consistency checks – like a software build Really shouldn’t require much guidance to read, but a few things to call out Objective of spec is developer can skim and decide in < day Show the search (search for tag)
  2. You’re a message broker routing and translating between v2, v3 and FHIR Your app interfaces with a PHR using FHIR natively Your application can communicate using FHIR, but your software uses a proprietary RDBMS Use FHIR as the common language for a Vendor Neutral Archive …Or a combination…. You might see data as a nested structure of XML, a series of tables with keys, class-diagrams….
  3. FHIR can be your shared persistence layer – nice granularity for storage, extensions for handling “extra” stuff easily FHIR can be the common model for your mapping layer FHIR can be the logical model used for decision support, both to expose your data to the decision support engine as well as to define rules (work in progress with vMR-CDS and CQI)
  4. Review
  5. Chained – query across referenced resources - GET [base-url]/DiagnosticReport?subject.name=peter Tags: security, profile, general Examples if have time http://fhir.healthintersections.com.au/open/Patient?name=eve http://fhir.healthintersections.com.au/open/Condition?subject=84238862 http://fhir.healthintersections.com.au/open/patient/84238862/Condition Standard search parameters
  6. Example of sync DocumentRefrences – a DHB could maintain a local cache
  7. * the deletion operation should be understood as deleting the record of the resource, with nothing about the state of the real-world corresponding resource implied.
  8. * Now, if you query for /server.org/fhir/patient/@33, you get a 410
  9. * The resource returns back to life!
  10. Not talking about REST in general, but rather FHIR’s implementation of REST
  11. Todo: more specifics from Grahame. Removed: No natural “server” or no fixed network location
  12. Note that easier in NZ as we locked CDA down.
  13. A Document, no matter how nested, is flattened to a list of entries, the Document’s header being the first. The document header (and any other the other resources) refer to each other using normal references to reflect the document’s nesting. Of course, there may be a digital signature (on the whole Bundle) to attest to the content of the document.
  14. Talk about how functions as the CDA header
  15. Furore server – id NZ100 Talk about conversion
  16. You can retrieve any patient using a GET on the patient’s id, which is just an url on the server: /fhir/Patient/<id> We have our own MIME-type: “application/xml+fhir” and “application/json+fhir”
  17. Mobile, social web, green field are most likely adopters, though significant interest from other quarters
  18. This is not only the URL you use to retrieve the resource, it’s also its id. All URL’s in FHIR are case-sensitive (and so is the id) It is *metadata*, you won’t find this in the Resource’s definition
  19. Resource Id’s (=URLs) are infrastructural id’s, they differ from “business” identifier. Many Resources also have business identifiers, they are explicitly modeled, like Patient.identifier (even more than one identifier possible!) Business identifiers are completely separate from technical resource id’s
  20. Only the Resources are user-definable, other types are “built-in” Derived primitives are patterns -> validation consists of regexp matching Constrained types are defined using invariants (OCL, Xpath, prose) -> validation using schematron, code Narrative and Extension are both ONLY used in Resources Resources can use both (derived) primitives and composite datatypes in its definitions Infrastructural types need special handling, not general-purpose types
  21. Resources SHOULD always contain narrative to support human-consumption as a fallback. However, in a strictly managed trading systems where all systems share a common data model and additional text is unnecessary or even a clinical safety risk, the narrative may be omitted.  generated The contents of the narrative are entirely generated from the structured data in the resource. extensions The contents of the narrative are entirely generated from the structured data in the resource and some of the content is generated from extensions. additional The contents of the narrative contain additional information not found in the structured data. empty the contents of the narrative are some equivalent of "No human-readable text provided for this resource".
  22. References can be in the same bundle, on the same server, on a different server
  23. Can expand value set
  24. See how the resource meta-data is mapped to equivalent Atom members Author is required by atom, so you’ll have to keep track who authored the resource, which might well be the user that POSTed it to your RESTful endpoint Summary is optional, but it is easy to fill it with the Resource’s <text> (human readable narrative), so Feed readers have a way to display the contents of a resource. Yes, this means the summary is present twice in the entry. All elements you see here are Atom spec, not FHIR
  25. See how the resource meta-data is mapped to equivalent Atom members Author is required by atom, so you’ll have to keep track who authored the resource, which might well be the user that POSTed it to your RESTful endpoint Summary is optional, but it is easy to fill it with the Resource’s <text> (human readable narrative), so Feed readers have a way to display the contents of a resource. Yes, this means the summary is present twice in the entry. All elements you see here are Atom spec, not FHIR
  26. Imagine that all resources in a single bundle Links maintain references Comment on new recources (cid: id’s)
  27. Specify data types – eg if deceased then must be datetime not boolean
  28. A ‘hierarchy’ of profiles The higher up the more likely to be reused
  29. Really any FHIR element (Resource, Datatype, Primitive) can be extended. Just nest an <extension> element under the thing you want to extend You should be able to go to the formal definition endpoint and get the definition of the extension. Note: birth order is already provided for in FHIR through the multipleBirthInteger
  30. Especially in HTTP space lots of work done – why re-invent? Application ‘knows’ user and rights, can deliver content as appropriate No concept of an ‘incomplete’ response to a query (could define tag in bundle if required)