HL7 FHIR Training course

Transcription

1 HL7 FHIR Training course in 4 hours! Ewout Kramer March 2014 Name (SSID): Password:

2 Who am I? Name: Ewout Kramer Company: Furore, Amsterdam Background: FHIR core team, RIMBAA Software developer & healthcare architect Contact:

3 Introduce ourselves About your organization HL7 (v2/v3) background? How did you hear about FHIR? Platform of choice (.NET, Java, Ruby, )? Familiar with HTTP, Xml, JSON, REST? Persistence technologies used?

4 Program Introduction to FHIR the Resource and REST Exercise #1 Deconstructing the FHIR data model Exercise #2 Bundles, Documents and Messages Exercise #3 Optional: Profiles and Conformance Optional: The HL7 family & FHIR

5 INTRODUCTION TO FHIR

6 Relative No technology can make integration as fast as we d like That s why we re here Building blocks more on these to follow

7 The Need How can I get data from my server to my ios app? How do I connect my applications using cloud storage? How can I give record-based standardized access to my PHR?

8 Highrise 2012 HL7 International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. 8 U.S. TM Office.

9 FHIR Manifesto Focus on implementers Keep common scenarios simple Leverage existing technologies Provide human readability Make content freely available Demonstrate best practice governance

10 WHAT S IN THE BOX?

11 Resources Patient Prescription

12 Resources Resources are: Small logically discrete units of exchange Defined behaviour and meaning Known identity / location Smallest unit of transaction of interest to healthcare V2: Sort of like Segments V3: Sort of like CMETs

13 The 80/20 rule Design for the 80%, not 100% Only include data elements in the artifacts if 80% of all implementers of that artifact will use the data element Allow easy extension for the remaining 20% of elements which often make up 80% of current specs Vocabulary approach to extension definition

14 Extensibility + =

15 The Case for Extensions Simple choice design for absolutely everything or allow extensions Everyone needs extensions, everyone hates them Define, publish, find extensions Repository Documented just like resources Can be fetched & interpreted by clients

16 Extending a multiple birth Key = location of formal definition Value = value according to definition

17 Transport HTTP/ OK Content-Type: application/json;charset=utf-8 Content-Length: 627 Content-Location: Last-Modified: Tue, 29 May :45:32 GMT ETag: "1 "Person":{"id":{"value":"1"},"identifier":[{"type":{"co de":"ssn","system":"

18 Paradigms FHIR supports 4 interoperability paradigms REST Documents Messages Services

19 Cross-paradigms Regardless of paradigm the content is the same This means it s straight-forward to share content across paradigms E.g. Receive a lab result in a message. Package it in a discharge summary document It also means constraints can be shared across paradigms E.g. Define a profile for Blood Pressure and use it on resources in messages, documents, REST and services

20 Looking at FHIR Resources from a software engineering perspective DESIGN OF THE RESOURCE

21 Structure of a Resource Metadata Resource Narrative Elements Extensions Extensions

22 Structure of a Resource (XML example)

23 Human Readable CDA taught HL7 a very important lesson Even if the computers don t understand 99% of what you re sending, that s ok if they can properly render it to a human clinician This doesn t just hold for documents important for messages, services, etc. In FHIR, every resource is required to have a human-readable expression Can be direct rendering or human entered

24 Narrative

25 Resources in the spec Let s take a look at some Resources in the specification.

26 Composition vs. reference FHIR makes composition and references explicit: References are in between Resources. No context conduction across references safe retrieval as individual resources. Composition is within a Resource: Components have no meaning outside resource, no identity, no separate access path except through resource

27 Composition of a Resource Resource Root Resource Component Simple & Complex elements (may be repeating)

28 Composition

29 Resource Reference DiagnosticReport Refers to Note: No referential integrity references are just URL s

30 References

31 Network subject performer organization

32 Business identifiers

33 A Resource s identity In fact: an URL resource type endpoint identifier

34 Resource metadata Metadata Patient MRN Ewout Kramer Amsterdam Resource Identities Last updated T23:33:01+01:

35 How FHIR uses RESTful principles to communicate Resources REST SERVICE INTERFACE

36

37 Just a quick GET GET /fhir/patient/1 HTTP/1.1 HTTP Verb + path HTTP/ OK Content-Type: application/xml+fhir;charset=utf-8 Content-Length: 787 Content-Location: Last-Modified: Tue, 29 May :45:32 GMT UTF-8 encoded <?xml version="1.0" encoding="utf-8"?> <Patient xmlns=" </use><family>everywoman</family><given>eve</given></name><telecom><system>phone</system><value> </value><use>work</use></telecom><gender><system> <code>f</code></gender><birthdate> </birthdate><address><use>home</use><line>2222 Home Street</line></address><text><status>generated</status><div xmlns=" Eve. SSN: </div></text></Patient> See the BOM?

38 A Resource s REST identity In fact: an URL resource type endpoint identifier Note: This URL resolves to the current version of a resource

39 REST representations GET /fhir/patient/1?_format=json HTTP/1.1 HTTP/ OK Content-Type: application/json+fhir;charset=utf-8 Content-Length: 787 GET /fhir/patient/1 HTTP/1.1 Accept: application/json+fhir HTTP/ OK Content-Type: application/json+fhir;charset=utf-8 Content-Length: 787

40 Remember metadata? Metadata Patient MRN Ewout Kramer Amsterdam Resource Identities Last updated T23:33:01+01:

41 Mapping (meta)data to HTTP Resource data Resource id Resource version Last update date Tags http body Url Content-Location header Last-Modified header Category header

42 Tag metadata GET /fhir/patient/1 HTTP/1.1 HTTP/ OK Content-Location: Last-Modified: Tue, 29 May :45:32 GMT Category: scheme=" label="our test tag" A general tag A profile tag - a claim that the Resource conforms to the profile identified in the term A security label

43 REST in the spec Let s look at these operations in the specification.

44 Mapping to verbs create The create interaction creates a new resource in a server assigned location. The create interaction is performed by an HTTP POST operation as shown: POST [service-url]/[resourcetype] (?_format=mimetype) read The read interaction accesses the current contents of a resource. The interaction is performed by an HTTP GET operation as shown: GET [service-url]/[resourcetype]/{id} (?_format=mimetype) update The update interaction creates a new current version for an existing resource or creates a new resource if no resource already exists for the given id. The update interaction is performed by an HTTP PUT operation as shown: PUT [service-url]/[resourcetype]/{id} (?_format=mimetype) delete The delete interaction removes an existing resource. The interaction is performed by an HTTP DELETE operation as shown: DELETE [service-url]/[resourcetype]/{id}

45 Exercise #1 Fiddling around with Fiddler & Getting data from a FHIR test server (45 minutes)

46 Break! Coffeebreak 15 minutes

47 The basic building blocks of FHIR DECONSTRUCTING THE FHIR DATAMODEL

48 Let s look at datatypes Composite Metadata Datatypes (HumanName, Quantity, Period, Narrative use Resource Address, Identifier ) Elements Constrained Types (Quantity: Distance, Count, Duration, Money) use Extensions Extensions use Primitives (integer, boolean, string, instant) Derived Primitives (oid, uuid, code, id)

49 Primitives - peculiarities boolean xs:boolean Values can be either true or false integer xs:int A signed 32-bit integer decimal instant xs:decimal xs:datetime A rational number. A true decimal, with inbuilt precision (e.g. Java BigDecimal) An instant in time - known at least to the second and always includes a timezone. uri xs:anyuri A Uniform Resource Identifier Reference. date union of xs:date, xs:gyearmonth, xs:gyear A date, or partial date as used in human communication. No time zone. datetime union of xs:datetime, xs:date, xs:gyearmonth, xs:gyear A date, date-time or partial date as used in human communication. If hours and minutes are specified, a time zone must be populated.

50 Level up: Composite Datatypes

51 Datatypes Let s take a look at the Data Types section of the FHIR specification at

52 Coded types Codes are defined in code systems

53 Coded types When used in a Resource, the modelers include Bindings Bindings specify which codes can be used

54

55 Exercise #2 Editing a Resource Instance - by hand! (45 minutes)

56 Using VS / Eclipse Eclipse: You need the Xml editing tools and add <Patient xmlns=" xmlns:xsi=" xsi:schemalocation=" VisualStudio: Go to Xml/Schemas then add fhir-all.xsd

57 SEARCH FUNCTIONALITY

58 Search (patient) Each search parameter has a type Parameter Type

59 Ok I get it or not? hits hits hits Total: = hits hits hits 5 hits Total: = 406

60 Chained searches Patient has a search for name. Observation has a search for subject (the id of the Patient, Group or Device) How do I find Observations for a patient, searching using his name?

61 2 queries in 1 You (as a client) don t need to do separate operations, just one: subject.name=jim But note: this still only works on the predefined search parameters. You cannot just use any property of the resource.

62 More optimalizations Say we do: We get back: a Bundle with 0..* Observations Now, usually, wouldn t we want the Patient information too? => Need to do N queries for the Observation s subject Quicker:?_include=Observation.subject Returns both Observations + Patients

63 How FHIR uses Atom to communicate sets of resources BUNDLES

64 Communicating lists We need to communicate lists of Resources Search result History Documents or messages Multiple-resource inserts ( batches ) So, we need an industry-standard to represent lists, and a place to put our metadata

65 Resource Bundle Metadata Metadata Bundle Resource Resource Narrative Elements Extensions Resource Extensions

66 Bundles Atom RFC Tombstones RFC 6721 Poll-based protocol for keeping up-to-date with newsfeeds (RSS and Atom) You can subscribe to a FHIR feed and get updates

67 New reports in the mail

68 An example Bundle

69 Resource metadata Metadata Patient MRN Ewout Kramer Amsterdam Resource Identity Last updated T23:33:01+01:

70 Resource Entry Resource id Last modified Tags Resource content Human-readable form, just like Resource.text

71 How FHIR supports documents and messages BEYOND REST

72 What s a document? Persistence: continues to exist in an unaltered state Stewardship: maintained by a person or organization entrusted with its care. Potential for authentication: an assemblage of information that is intended to be legally authenticated. Wholeness. Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document. Human readability. A clinical document is human readable.

73 The Document resource A single Resource, very often a List

74 Documents are bundles Composition Resource Metadata Section Attester Section Observation Resource Device Resource Prescription Resource Patient Resource <feed> <entry> <Composition /> </entry> <entry> <Observation /> </entry> <entry> <Device /> </entry> <entry> <Prescription /> </entry> <entry> <Patient /> </entry> </feed>

75 Tag as Document This Bundle is a Document

76 Communicating documents You can drop your document on No storage or disassembly is implied, your just posting a document in its entirety. Servers can implement any specific functionality as required between trading partners when receiving such a document.

77 Communicating documents You can store your document using Storage, NO disassembly is implied, document (and signature) stays intact Search is supported (you search on it s Message header Composition) NEW!

78 MessageHeader Resource

79 Messages are bundles Message Resource source destination event Observation Resource Device Resource Patient Resource <feed> <entry> <MessageHeader /> </entry> <entry> <Observation /> </entry> <entry> <Patient /> </entry> <entry> <Device /> </entry> </feed>

80 Tag as Message This Bundle is a Message

81 Sending messages Again, REST not necessary, but There is an explicit REST endpoint: No storage implied. Might be a router, converted to v2, etc. etc. The server can process them based on the event code and return the response as another message (again a bundle).

82 Resolving a reference 82

83 Exercise #3 Composing a Document (45 minutes)

84 Introducing PROFILES, VALIDATION AND CONFORMANCE

85 The need for Profiles Many different contexts in healthcare, but a single set of Resources Need to be able to describe restrictions based on use and context Allow for these usage statements to: Authored in a structured manner Published in a repository Used as the basis for validation, code, report and UI generation.

86 Profiling a resource Demand that the identifier uses your national patient identifier 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 RaceCode Note: hardly any mandatory elements in the core spec!

87 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 resource is simply referred to by its URI: e.g.

88 Using profiles When communicating a resource, you can indicate the profiles it conforms to. A server might explicitly state it only accepts resources conforming to a certain profile (and verify!) You can ask a FHIR server to validate a resource against a given profile

89 Tagging a Resource Patient MRN Ewout Kramer Amsterdam a claim that the Resource conforms to the profile identified in the term

90 Who publishes?

91 What s in a profile? Metadata Identifier Name, Version Publisher Description, Code Status Date (of publication) Resource and Datatype Constraints Extension Conformance Resource (via Tag) Extension in Resource ValueSet ValueSet

92 (Distributed) validation App s server Store & Validate Country validation server Profile X Profile Y Validate Profile Y

93 Operation Outcome When something goes wrong.return the OperationOutcome Resource!

94 Conformance There s a resource for documenting conformance to FHIR Can be used for: Stating how a specific system instance behaves Defining how a software system is capable of behaving (including configuration options) Identifying a desired set of behavior (e.g. RFP) To declare themselves FHIR Conformant, a system must publish a Conformance instance

95 Conformance Resource Which wire formats supported? Which resources? What documents, messages does the server accept, what does the content look like? Which protocols? http? Mllp? ftp? Which operations (read, create, update, search) Which FHIR version? What search operations? Is this a test server? Who can I contact? What s the name of the software?

96 How to get conformance Conformance is again, just a Resource Any FHIR server will publish his own conformance at a special endpoint A FHIR server may store and publish any number of additional Conformance resources, so you can refer to them Able to validate by automated testing

97 HL7 FAMILY AND FHIR

98 V2 and FHIR Similarities Built around re-usable chunks of data Strong forward/backward compatibility rules Extensibility mechanism FHIR Differences Each chunk (resource) is independently addressable More than messages Human readable required Extensions don t collide, are discoverable Modern tools/skills Instances easy to read Lighter spec

99 Migration v2 Already have an integration engine that supports translation between v2 and FHIR Resources map to segments reasonably well As always, the challenge with v2 mapping is the variability of v2 interfaces Common mappings can be created, but they won t be one size fits all HL7 v2

100 and v2 mappings Every Resource has v2 mappings specified, e.g.: Patient identifier name telecom gender birthdate deceased[x] address maritalstatus PID-3 PID-5, PID-9 PID-13, PID-14, PID-40 PID-8 PID-7 PID-30 PID-11 PID-16

101 V3 and FHIR Similarities Based on RIM, vocab & ISO Data types foundations Support XML syntax FHIR Differences Simpler models & syntax (reference model hidden) Friendly names Extensibility with discovery Easy inter-version wire compatibility Messages, documents, etc. use same syntax JSON syntax too

102 CDA and FHIR Similarities Support profiling for specific use-cases Human readability is minimum for interoperability APIs, validation tooling, profile tooling (See v3 similarities on prior slide) FHIR Differences Can use out of the box no templates required Not restricted to just documents Implementer tooling generated with spec (See v3 differences on prior slide)

103 Migration CDA Made more complex by human-readable nature Need to ensure text <-> entry linkages are retained Will best be handled on a template by template basis Likely start with important ones like C-CDA

104 and v3 mappings Every Resource has v3 mappings specified, e.g.: Patient identifier name telecom gender birthdate deceased[x] address maritalstatus multiplebirth[x] Patient./id./name./telecom./administrativeGender./birthTime./deceasedInd./addr./maritalStatus.multipleBirthInd

105 FHIR and Services Similarities Encourage context neutral, re-usable structures with defined behavior RESTful interface is a simple SOA interface FHIR differences Consistent data structures across services Ease of transport across paradigms message <-> service <-> document <-> REST Standard framework for defining/discovering services

106 So why use anything else? FHIR is brand new No market share Only recently passed DSTU ballot Little track record Business case No-one dumps existing working systems just because something new is better Large projects committed to one standard won t change direction quickly (or even at all)

107 (XDS) references A document reference resource is used to describe a document that is made available to a healthcare system. Document Reference Resources are used in document indexing systems, and are used to refer to: CDA documents in FHIR systems FHIR documents stored elsewhere (i.e. registry/repository following the XDS model) PDF documents, and even digital records of faxes where sufficient information is available Other kinds of documents, such as records of prescriptions.

108 IHE MHD This winter ( ) the Volume 2 part of Mobile Health Documents (MHD) will be replaced with the appropriate content describing a profile of DocumentReference to meet the needs of MHD and the family of Document Sharing in XDS, XDR, and XCA. John Moehrke, august 16, 2013

109 Balloting plans First Draft Standard for Trial Use ballot (DSTU) complete Recently HL7 decided FHIR is now published as a DSTU Will provide a semi-stable platform for implementers while still allowing non-backward-compatible change for Normative version if implementation experience dictates Additional DSTU versions roughly annually to make fixes, introduce new resources Normative is around 3 years out We want *lots* of implementation experience before committing to backward compatibility 110

110 Next Steps for you Read the spec: Try implementing it Come to a (European?) Connectathon! [email protected] #FHIR Implementor s Skype Channel FHIR Developer Days (November 24 26), Amsterdam StackOverflow: hl7 fhir tag

111 The End Questions?