This result is being rendered in HTML for easy viewing. You may access this content as Raw JSON or Raw XML, or view this content in HTML JSON or HTML XML. Response generated in 19ms.

HTTP 200 OK

Response Headers

Date: Wed, 01 Apr 2020 20:39:30 GMT
X-Powered-By: HAPI FHIR 5.0.0-SNAPSHOT REST Server (FHIR Server; FHIR 4.0.1/R4; Raccoon Nation Edition)
Content-Type: application/fhir+xml;charset=utf-8
X-Request-ID: mmrVf9w2Zn8Kfkfi

Response Body

{
"resourceType": "Bundle",
"id": "eccbde22-2cc4-42f5-87c7-a6d8dd5715b1",
"meta": {
"lastUpdated": "2020-04-01T20:39:30.846+00:00"
},
"type": "searchset",
"total": 7,
"link": [ {
"relation": "self",
"url": "https://smilecdr.com/hapi-fhir/blog/fhir/baseR4/Communication"
} ],
"entry": [ {
"fullUrl": "https://smilecdr.com/hapi-fhir/blog/fhir/baseR4/Communication/20200215_hapi_fhir_4_2_0",
"resource": {
"resourceType": "Communication",
"id": "20200215_hapi_fhir_4_2_0",
"meta": {
"versionId": "1",
"tag": [ {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Release"
} ]
},
"language": "en",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>It's time for another release of HAPI FHIR!</p>\n<p>This release brings some good stuff, including:</p>\n<ul>\n<li>\n<p>A new database migrator for the JPA server has been introduced, based on FlywayDB.</p>\n</li>\n<li>\n<p>A major performance enhancement has been added to the parser, which decreases the parse time when parsing large Bundle resources by up to 50%.</p>\n</li>\n<li>\n<p>Support for positional (near) search using geo-coordinates and positional distance has been added. This support currently uses a &quot;bounding box&quot; algorithm, and may be further enhanced to use a radius circle in the future.</p>\n</li>\n<li>\n<p>Support for LOINC 2.67 has been added</p>\n</li>\n</ul>\n<p>As always, see the <a href=\"https://smilecdr.com/hapi-fhir/docs/introduction/changelog.html\">changelog</a> for a full list of changes.</p>\n<p>Thanks to everyone who contributed to this release!</p>\n</div>"
},
"status": "completed",
"sent": "2020-02-15T10:00:00-05:00",
"sender": {
"reference": "https://smilecdr.com/about_us/#james",
"display": "James Agnew"
},
"payload": [ {
"contentString": "<p>It's time for another release of HAPI FHIR!</p>\n<p>This release brings some good stuff, including:</p>\n<ul>\n<li>\n<p>A new database migrator for the JPA server has been introduced, based on FlywayDB.</p>\n</li>\n<li>\n<p>A major performance enhancement has been added to the parser, which decreases the parse time when parsing large Bundle resources by up to 50%.</p>\n</li>\n<li>\n<p>Support for positional (near) search using geo-coordinates and positional distance has been added. This support currently uses a &quot;bounding box&quot; algorithm, and may be further enhanced to use a radius circle in the future.</p>\n</li>\n<li>\n<p>Support for LOINC 2.67 has been added</p>\n</li>\n</ul>\n<p>As always, see the <a href=\"https://smilecdr.com/hapi-fhir/docs/introduction/changelog.html\">changelog</a> for a full list of changes.</p>\n<p>Thanks to everyone who contributed to this release!</p>\n"
} ]
}
}, {
"fullUrl": "https://smilecdr.com/hapi-fhir/blog/fhir/baseR4/Communication/20191113_hapi_fhir_4_1_0",
"resource": {
"resourceType": "Communication",
"id": "20191113_hapi_fhir_4_1_0",
"meta": {
"versionId": "1",
"tag": [ {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Release"
} ]
},
"language": "en",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>It's time for another release of HAPI FHIR!</p>\n<p>This release brings some good stuff, including:</p>\n<ul>\n<li>\n<p>Structures JARs have been updated to incorporate the latest technical corrections. DSTU3 structures are upgraded to FHIR 3.0.2, R4 structures are upgraded to\tFHIR 4.0.1, and R5 draft structures are upgraded to the October 2019 draft revision.</p>\n</li>\n<li>\n<p>ValueSets are now automatically pre-expanded by the JPA server into a dedicated set of database tables. This &quot;precalculated expansion&quot; is used to provide much better performance for validation and expanion operations, and introduced the ability to successfully expand very large ValueSets such as the LOINC implicit (all codes) valueset.</p>\n</li>\n<li>\n<p>Support for the FHIR Bulk Export specification has been added. We are now\tworking on adding support for Bulk Import!</p>\n</li>\n<li>\n<p>First-order support for ElasticSearch as a full-text and terminology service backend implementation. At this time, both raw Lucene and ElasticSearch are supported (this may change in the future but we do not have any current plans to deprecate Lucene).</p>\n</li>\n<li>\n<p>Live Terminology Service operations for terminology file maintenance based on delta files has been added.</p>\n</li>\n<li>\n<p>Binary resources and Media/DocumentReference instances with binary attachments stored in the FHIR repository can now take advantage of externalized binary storage for the binary content when that feature is enabled. This allows much better scalability of repositories containing large amounts of binary content (e.g. document repositories).</p>\n</li>\n</ul>\n<p>As always, see the <a href=\"https://smilecdr.com/hapi-fhir/docs/introduction/changelog.html\">changelog</a> for a full list of changes.</p>\n<p>Thanks to everyone who contributed to this release!</p>\n<p>Also, as a reminder, if you have not already filled out our annual user survey, please take a moment to do so. Access the survey here:\t<a href=\"http://bit.ly/33HO4cs\">http://bit.ly/33HO4cs</a> (note that this URL was originally posted incorrectly. It is now fixed)</p>\n</div>"
},
"status": "completed",
"sent": "2019-11-13T10:00:00-05:00",
"sender": {
"reference": "https://smilecdr.com/about_us/#james",
"display": "James Agnew"
},
"payload": [ {
"contentString": "<p>It's time for another release of HAPI FHIR!</p>\n<p>This release brings some good stuff, including:</p>\n<ul>\n<li>\n<p>Structures JARs have been updated to incorporate the latest technical corrections. DSTU3 structures are upgraded to FHIR 3.0.2, R4 structures are upgraded to\tFHIR 4.0.1, and R5 draft structures are upgraded to the October 2019 draft revision.</p>\n</li>\n<li>\n<p>ValueSets are now automatically pre-expanded by the JPA server into a dedicated set of database tables. This &quot;precalculated expansion&quot; is used to provide much better performance for validation and expanion operations, and introduced the ability to successfully expand very large ValueSets such as the LOINC implicit (all codes) valueset.</p>\n</li>\n<li>\n<p>Support for the FHIR Bulk Export specification has been added. We are now\tworking on adding support for Bulk Import!</p>\n</li>\n<li>\n<p>First-order support for ElasticSearch as a full-text and terminology service backend implementation. At this time, both raw Lucene and ElasticSearch are supported (this may change in the future but we do not have any current plans to deprecate Lucene).</p>\n</li>\n<li>\n<p>Live Terminology Service operations for terminology file maintenance based on delta files has been added.</p>\n</li>\n<li>\n<p>Binary resources and Media/DocumentReference instances with binary attachments stored in the FHIR repository can now take advantage of externalized binary storage for the binary content when that feature is enabled. This allows much better scalability of repositories containing large amounts of binary content (e.g. document repositories).</p>\n</li>\n</ul>\n<p>As always, see the <a href=\"https://smilecdr.com/hapi-fhir/docs/introduction/changelog.html\">changelog</a> for a full list of changes.</p>\n<p>Thanks to everyone who contributed to this release!</p>\n<p>Also, as a reminder, if you have not already filled out our annual user survey, please take a moment to do so. Access the survey here:\t<a href=\"http://bit.ly/33HO4cs\">http://bit.ly/33HO4cs</a> (note that this URL was originally posted incorrectly. It is now fixed)</p>\n"
} ]
}
}, {
"fullUrl": "https://smilecdr.com/hapi-fhir/blog/fhir/baseR4/Communication/20190814_hapi_fhir_4_0_0",
"resource": {
"resourceType": "Communication",
"id": "20190814_hapi_fhir_4_0_0",
"meta": {
"versionId": "1",
"tag": [ {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Release"
} ]
},
"language": "en",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>The next release of HAPI has now been uploaded to the Maven repos and GitHub's releases section.</p>\n<p>This release features a number of significant performance improvements, and has some notable changes:</p>\n<ul>\n<li>\n<p>A new consent framework called ConsentInterceptor that can be used to apply local consent directives and policies, and potentially filter or mask data has been added.</p>\n</li>\n<li>\n<p>Initial support for draft FHIR R5 resources has been added.</p>\n</li>\n<li>\n<p>Support for GraphQL and the _filter search parameter has been added.</p>\n</li>\n<li>\n<p>The ability to perform cascading deletes has been added.</p>\n</li>\n</ul>\n<p>As always, see the <a href=\"https://smilecdr.com/hapi-fhir/docs/introduction/changelog.html\">changelog</a> for a full list of changes.</p>\n<p>Thanks to everyone who contributed to this release!</p>\n</div>"
},
"status": "completed",
"sent": "2019-08-14T10:00:00-05:00",
"sender": {
"reference": "https://smilecdr.com/about_us/#james",
"display": "James Agnew"
},
"payload": [ {
"contentString": "<p>The next release of HAPI has now been uploaded to the Maven repos and GitHub's releases section.</p>\n<p>This release features a number of significant performance improvements, and has some notable changes:</p>\n<ul>\n<li>\n<p>A new consent framework called ConsentInterceptor that can be used to apply local consent directives and policies, and potentially filter or mask data has been added.</p>\n</li>\n<li>\n<p>Initial support for draft FHIR R5 resources has been added.</p>\n</li>\n<li>\n<p>Support for GraphQL and the _filter search parameter has been added.</p>\n</li>\n<li>\n<p>The ability to perform cascading deletes has been added.</p>\n</li>\n</ul>\n<p>As always, see the <a href=\"https://smilecdr.com/hapi-fhir/docs/introduction/changelog.html\">changelog</a> for a full list of changes.</p>\n<p>Thanks to everyone who contributed to this release!</p>\n"
} ]
}
}, {
"fullUrl": "https://smilecdr.com/hapi-fhir/blog/fhir/baseR4/Communication/20180211_fhir_and_the_hype_cycle",
"resource": {
"resourceType": "Communication",
"id": "20180211_fhir_and_the_hype_cycle",
"meta": {
"versionId": "1",
"tag": [ {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Hype Cycle"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "HL7"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "HL7v2"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "FHIR"
} ]
},
"language": "en",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>One of the things we often talk about in the FHIR standards development community is where FHIR currently sits on Gartner's <a href=\"https://www.gartner.com/technology/research/methodologies/hype-cycle.jsp\">Hype Cycle</a>. The hype cycle is a coarse measure of the trajectory of new technologies on a journey from being &quot;new and exciting silver bullets&quot; to eventually being &quot;boring useful technologies&quot;.</p>\n<p>When you are a proponent of a new technology (as I certainly am with FHIR), probably the most important aspect to remember about the hype cycle is that you really only ever know where you are at any given time long after that time has passed. In other words, it's fun to ask yourself &quot;have we passed the Peak of Inflated Expectations yet?&quot; but you really won't know until much later.</p>\n<p>Speculating is perhaps a fool's errand. I probably shouldn't try but I can't help but wonder if we have passed the peak yet.</p>\n<p>The trajectory of <a href=\"http://hapifhir.io\">HAPI FHIR</a>'s growth is interesting. FHIR has been growing over the last few years by all kinds of metrics. The connectathons keep getting bigger, the number of vendors participating keeps on getting bigger, and <a href=\"https://www.fhirdevdays.com/\">FHIR DevDays</a> keeps on getting bigger.</p>\n<p>If I look at our website in Google Analytics, I am curious about the trajectory.</p>\n<img src=\"20180211_fhir_and_the_hype_cycle/hapi-growth.png\" style=\"width: 100%; height: auto;\"/>\n<p>While HAPI FHIR has seen pretty steady growth over the last few years, that growth has been either tapering or at least very unstable over the last 8 months.</p>\n<p>Certainly I don't think HAPI FHIR has stopped growing. The number of messages on the support forum and the number of people with big production implementations these days certainly doesn't suggest that; however, things have certainly been weird the last 8 months.</p>\n<p>Let's look at interest in FHIR overall. The next thing to look at is the <a href=\"https://trends.google.com/trends/explore?date=2014-02-11%202018-02-11&amp;q=fhir\">FHIR Google Trends</a> graph, which measures the number of people searching for terms on Google (a pretty decent indicator of general interest). The following graph shows the last 4 years for FHIR.</p>\n<img src=\"20180211_fhir_and_the_hype_cycle/fhir-trends.png\" style=\"width: 100%; height: auto;\"/>\n<p>It would seem that FHIR itself saw a crazy explosion of interest back in May, too. That makes sense since FHIR R3 was released right before that peak.</p>\n<p>Let's compare that with the graph for <a href=\"http://ihe.net\">IHE</a>. I don't think anyone would disagree that IHE sits firmly atop the Plateau of Productivity. Most people in the world of health informatics know what can be accomplished with IHE's profiles, and certainly I've worked with many organizations who use them to accomplish good things.</p>\n<p>The <a href=\"https://trends.google.com/trends/explore?date=2014-02-11%202018-02-11&amp;q=fhir,ihe\">FHIR and IHE Graph</a> shows interest in <span style=\"color: #48F; font-weight: bold;\">FHIR in BLUE</span> and <span style=\"color: #F00; font-weight: bold;\">IHE in RED</span>.</p>\n<img src=\"20180211_fhir_and_the_hype_cycle/fhir-ihe-trends.png\" style=\"width: 100%; height: auto;\"/>\n<p>So what can we take from this? I think the right side of the graph is quite interesting. FHIR itself has kind of levelled off recently and has hit similar metrics to those of a very productive organization.</p>\n<p>I probably shouldn't attach too much meaning to these graphs, but I can't help but wonder...</p>\n</div>"
},
"status": "completed",
"sent": "2018-02-11T15:06:00Z",
"sender": {
"reference": "https://smilecdr.com/about_us/#james",
"display": "James Agnew"
},
"payload": [ {
"contentString": "<p>One of the things we often talk about in the FHIR standards development community is where FHIR currently sits on Gartner's <a href=\"https://www.gartner.com/technology/research/methodologies/hype-cycle.jsp\">Hype Cycle</a>. The hype cycle is a coarse measure of the trajectory of new technologies on a journey from being &quot;new and exciting silver bullets&quot; to eventually being &quot;boring useful technologies&quot;.</p>\n<p>When you are a proponent of a new technology (as I certainly am with FHIR), probably the most important aspect to remember about the hype cycle is that you really only ever know where you are at any given time long after that time has passed. In other words, it's fun to ask yourself &quot;have we passed the Peak of Inflated Expectations yet?&quot; but you really won't know until much later.</p>\n<p>Speculating is perhaps a fool's errand. I probably shouldn't try but I can't help but wonder if we have passed the peak yet.</p>\n<p>The trajectory of <a href=\"http://hapifhir.io\">HAPI FHIR</a>'s growth is interesting. FHIR has been growing over the last few years by all kinds of metrics. The connectathons keep getting bigger, the number of vendors participating keeps on getting bigger, and <a href=\"https://www.fhirdevdays.com/\">FHIR DevDays</a> keeps on getting bigger.</p>\n<p>If I look at our website in Google Analytics, I am curious about the trajectory.</p>\n<img src=\"20180211_fhir_and_the_hype_cycle/hapi-growth.png\" style=\"width: 100%; height: auto;\"/>\n<p>While HAPI FHIR has seen pretty steady growth over the last few years, that growth has been either tapering or at least very unstable over the last 8 months.</p>\n<p>Certainly I don't think HAPI FHIR has stopped growing. The number of messages on the support forum and the number of people with big production implementations these days certainly doesn't suggest that; however, things have certainly been weird the last 8 months.</p>\n<p>Let's look at interest in FHIR overall. The next thing to look at is the <a href=\"https://trends.google.com/trends/explore?date=2014-02-11%202018-02-11&amp;q=fhir\">FHIR Google Trends</a> graph, which measures the number of people searching for terms on Google (a pretty decent indicator of general interest). The following graph shows the last 4 years for FHIR.</p>\n<img src=\"20180211_fhir_and_the_hype_cycle/fhir-trends.png\" style=\"width: 100%; height: auto;\"/>\n<p>It would seem that FHIR itself saw a crazy explosion of interest back in May, too. That makes sense since FHIR R3 was released right before that peak.</p>\n<p>Let's compare that with the graph for <a href=\"http://ihe.net\">IHE</a>. I don't think anyone would disagree that IHE sits firmly atop the Plateau of Productivity. Most people in the world of health informatics know what can be accomplished with IHE's profiles, and certainly I've worked with many organizations who use them to accomplish good things.</p>\n<p>The <a href=\"https://trends.google.com/trends/explore?date=2014-02-11%202018-02-11&amp;q=fhir,ihe\">FHIR and IHE Graph</a> shows interest in <span style=\"color: #48F; font-weight: bold;\">FHIR in BLUE</span> and <span style=\"color: #F00; font-weight: bold;\">IHE in RED</span>.</p>\n<img src=\"20180211_fhir_and_the_hype_cycle/fhir-ihe-trends.png\" style=\"width: 100%; height: auto;\"/>\n<p>So what can we take from this? I think the right side of the graph is quite interesting. FHIR itself has kind of levelled off recently and has hit similar metrics to those of a very productive organization.</p>\n<p>I probably shouldn't attach too much meaning to these graphs, but I can't help but wonder...</p>\n"
} ]
}
}, {
"fullUrl": "https://smilecdr.com/hapi-fhir/blog/fhir/baseR4/Communication/20170208_custom_search_parameters",
"resource": {
"resourceType": "Communication",
"id": "20170208_custom_search_parameters",
"meta": {
"versionId": "1",
"tag": [ {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "SearchParameters"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "HAPI"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Development"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "FHIR"
} ]
},
"language": "en",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>HAPI FHIR's <a href=\"http://hapifhir.io/doc_jpa.html\" target=\"_blank\">JPA Module</a> lets you quickly set up a FHIR server, complete with a database for whatever purpose you might have.</p>\n<p>One of the most requested features in the last year has been for support of custom search parameters on that server. Out of the box, the JPA server has always supported the default/built-in search parameters that are defined in the FHIR specification.</p>\n<p>This means that if you store a <code>Patient</code> resource in the database, the <code>Patient.gender</code> field will be indexed with a search parameter called <code>gender</code>, the <code>Patient.birthDate</code> field will be indexed with a search parameter called <code>birthdate</code>, etc.</p>\n<p>To see a list of the default search parameters for a given resource, you can see a table near the bottom of any resource definition. For example, <a href=\"http://www.hl7.org/fhir/patient.html#search\" target=\"_blank\">here are the Patient search parameters</a>.</p>\n<h2>The Need for Custom Parameters</h2>\n<p>The built-in parameters are great for lots of situations but if you're building a real application backend then you are probably going to come up with a need that the FHIR specification developers didn't anticipate (or one that doesn't meet FHIR's 80% rule).</p>\n<p>The solution for this is to introduce a custom search parameter. Search parameters are defined using a resource that is – unsurprisingly – called <code>SearchParameter</code>. The idea is that you create one of these SearchParameter resources and give it a <code>code</code> (the name of the URL parameter), a <code>type</code> (the search parameter type), and an <code>expression</code> (the FHIRPath expression which will actually be indexed).</p>\n<h2>Custom Parameters in HAPI FHIR JPA</h2>\n<p>In HAPI FHIR's JPA server, custom search parameters are indexed just like any other search parameter. A new mechanism has been introduced in HAPI FHIR 2.3 (to be released soon) that parses the expression, adds any new or updated search parameters to an internal registry of indexed paths, and marks any existing resources that are potential candidates for this new search parameter as requiring reindexing.</p>\n<p>This means that any newly added search parameters will cover resources added after the search parameter was added, and it will also cover older resources after the server has had a chance to reindex them.</p>\n<p>This also means that you definitely want to make sure you have properly secured the <code>/SearchParameter</code> endpoint since it can potentially cause your server to do a lot of extra work if there are a lot of resources present.</p>\n<h2>Taking it for a Spin!</h2>\n<p>To show how this works, here is an example of a search parameter on an extension. We'll suppose that in our system we've defined an extension for patients' eye colour. Patient resources stored in our database will have the eye colour extension set, and we want to be able to search on this extension, too.</p>\n<p><strong>1. Create the Search Parameter</strong></p>\n<p>First, define a search parameter and upload it to your server. In Java, this looks as follows:</p>\n<pre><code class=\"language-java\">// Create a search parameter definition\nSearchParameter eyeColourSp = new SearchParameter();\neyeColourSp.addBase(&quot;Patient&quot;);\neyeColourSp.setCode(&quot;eyecolour&quot;);\neyeColourSp.setType(org.hl7.fhir.dstu3.model.Enumerations.SearchParamType.TOKEN);\neyeColourSp.setTitle(&quot;Eye Colour&quot;);\neyeColourSp.setExpression(&quot;Patient.extension('http://acme.org/eyecolour')&quot;);\neyeColourSp.setXpathUsage(org.hl7.fhir.dstu3.model.SearchParameter.XPathUsageType.NORMAL);\neyeColourSp.setStatus(org.hl7.fhir.dstu3.model.Enumerations.PublicationStatus.ACTIVE);\n// Upload it to the server\nclient\n\t.create()\n\t.resource(eyeColourSp)\n\t.execute();</code></pre>\n<p>The resulting SearchParameter resource looks as follows:</p>\n<pre><code class=\"language-json\">{\n\t&quot;resourceType&quot;: &quot;SearchParameter&quot;,\n\t&quot;title&quot;: &quot;Eye Colour&quot;,\n\t&quot;base&quot;: [ &quot;Patient&quot; ],\n\t&quot;status&quot;: &quot;active&quot;,\n\t&quot;code&quot;: &quot;eyecolour&quot;,\n\t&quot;type&quot;: &quot;token&quot;,\n\t&quot;expression&quot;: &quot;Patient.extension('http://acme.org/eyecolour')&quot;,\n\t&quot;xpathUsage&quot;: &quot;normal&quot;\n}</code></pre>\n<p><strong>2. Upload Some Resources</strong></p>\n<p>Let's upload two Patient resources with different eye colours.</p>\n<pre><code class=\"language-java\">Patient p1 = new Patient();\np1.setActive(true);\np1.addExtension().setUrl(&quot;http://acme.org/eyecolour&quot;).setValue(new CodeType(&quot;blue&quot;));\nclient\n\t.create()\n\t.resource(p1)\n\t.execute();\nPatient p2 = new Patient();\np2.setActive(true);\np2.addExtension().setUrl(&quot;http://acme.org/eyecolour&quot;).setValue(new CodeType(&quot;green&quot;));\nclient\n\t.create()\n\t.resource(p2)\n\t.execute();</code></pre>\n<p>Here's how one of these resources will look when encoded.</p>\n<pre><code class=\"language-json\">{\n &quot;resourceType&quot;: &quot;Patient&quot;,\n &quot;extension&quot;: [\n {\n &quot;url&quot;: &quot;http://acme.org/eyecolour&quot;,\n &quot;valueCode&quot;: &quot;blue&quot;\n }\n ],\n &quot;active&quot;: true\n}</code></pre>\n<p><strong>3. Search!</strong></p>\n<p>Finally, let's try searching:</p>\n<pre><code class=\"language-java\">Bundle bundle = ourClient\n\t.search()\n\t.forResource(Patient.class)\n\t.where(new TokenClientParam(&quot;eyecolour&quot;).exactly().code(&quot;blue&quot;))\n\t.returnBundle(Bundle.class)\n\t.execute();\nSystem.out.println(myFhirCtx.newJsonParser().setPrettyPrint(true).encodeResourceToString(bundle));</code></pre>\n<p>This produces a search result that contains only the matching resource:</p>\n<pre><code class=\"language-json\">{\n &quot;resourceType&quot;: &quot;Bundle&quot;,\n &quot;id&quot;: &quot;bc89e883-b9f7-4745-8c2f-24bf9277664d&quot;,\n &quot;meta&quot;: {\n &quot;lastUpdated&quot;: &quot;2017-02-07T20:30:05.445-05:00&quot;\n },\n &quot;type&quot;: &quot;searchset&quot;,\n &quot;total&quot;: 1,\n &quot;link&quot;: [\n {\n &quot;relation&quot;: &quot;self&quot;,\n &quot;url&quot;: &quot;http://localhost:45481/fhir/context/Patient?eyecolour=blue&quot;\n }\n ],\n &quot;entry&quot;: [\n {\n &quot;fullUrl&quot;: &quot;http://localhost:45481/fhir/context/Patient/2&quot;,\n &quot;resource&quot;: {\n &quot;resourceType&quot;: &quot;Patient&quot;,\n &quot;id&quot;: &quot;2&quot;,\n &quot;meta&quot;: {\n &quot;versionId&quot;: &quot;1&quot;,\n &quot;lastUpdated&quot;: &quot;2017-02-07T20:30:05.317-05:00&quot;\n },\n &quot;text&quot;: {\n &quot;status&quot;: &quot;generated&quot;,\n &quot;div&quot;: &quot;&lt;div xmlns=\\&quot;http://www.w3.org/1999/xhtml\\&quot;&gt;&lt;table class=\\&quot;hapiPropertyTable\\&quot;&gt;&lt;tbody/&gt;&lt;/table&gt;&lt;/div&gt;&quot;\n },\n &quot;extension&quot;: [\n {\n &quot;url&quot;: &quot;http://acme.org/eyecolour&quot;,\n &quot;valueCode&quot;: &quot;blue&quot;\n }\n ],\n &quot;active&quot;: true\n },\n &quot;search&quot;: {\n &quot;mode&quot;: &quot;match&quot;\n }\n }\n ]\n}</code></pre>\n<h2>Custom Search Parameters in Smile CDR</h2>\n<p>Naturally, this feature will soon be available in Smile CDR. Previous versions of Smile CDR had a less elegant solution to this problem; however, now that we have a nice elegant approach to custom parameters that is based on FHIR's own way of handling this, Smile CDR users will see the benefits quickly.</p>\n</div>"
},
"status": "completed",
"sent": "2017-02-07T20:35:00-05:00",
"sender": {
"reference": "https://smilecdr.com/about_us/#james",
"display": "James Agnew"
},
"payload": [ {
"contentString": "<p>HAPI FHIR's <a href=\"http://hapifhir.io/doc_jpa.html\" target=\"_blank\">JPA Module</a> lets you quickly set up a FHIR server, complete with a database for whatever purpose you might have.</p>\n<p>One of the most requested features in the last year has been for support of custom search parameters on that server. Out of the box, the JPA server has always supported the default/built-in search parameters that are defined in the FHIR specification.</p>\n<p>This means that if you store a <code>Patient</code> resource in the database, the <code>Patient.gender</code> field will be indexed with a search parameter called <code>gender</code>, the <code>Patient.birthDate</code> field will be indexed with a search parameter called <code>birthdate</code>, etc.</p>\n<p>To see a list of the default search parameters for a given resource, you can see a table near the bottom of any resource definition. For example, <a href=\"http://www.hl7.org/fhir/patient.html#search\" target=\"_blank\">here are the Patient search parameters</a>.</p>\n<h2>The Need for Custom Parameters</h2>\n<p>The built-in parameters are great for lots of situations but if you're building a real application backend then you are probably going to come up with a need that the FHIR specification developers didn't anticipate (or one that doesn't meet FHIR's 80% rule).</p>\n<p>The solution for this is to introduce a custom search parameter. Search parameters are defined using a resource that is – unsurprisingly – called <code>SearchParameter</code>. The idea is that you create one of these SearchParameter resources and give it a <code>code</code> (the name of the URL parameter), a <code>type</code> (the search parameter type), and an <code>expression</code> (the FHIRPath expression which will actually be indexed).</p>\n<h2>Custom Parameters in HAPI FHIR JPA</h2>\n<p>In HAPI FHIR's JPA server, custom search parameters are indexed just like any other search parameter. A new mechanism has been introduced in HAPI FHIR 2.3 (to be released soon) that parses the expression, adds any new or updated search parameters to an internal registry of indexed paths, and marks any existing resources that are potential candidates for this new search parameter as requiring reindexing.</p>\n<p>This means that any newly added search parameters will cover resources added after the search parameter was added, and it will also cover older resources after the server has had a chance to reindex them.</p>\n<p>This also means that you definitely want to make sure you have properly secured the <code>/SearchParameter</code> endpoint since it can potentially cause your server to do a lot of extra work if there are a lot of resources present.</p>\n<h2>Taking it for a Spin!</h2>\n<p>To show how this works, here is an example of a search parameter on an extension. We'll suppose that in our system we've defined an extension for patients' eye colour. Patient resources stored in our database will have the eye colour extension set, and we want to be able to search on this extension, too.</p>\n<p><strong>1. Create the Search Parameter</strong></p>\n<p>First, define a search parameter and upload it to your server. In Java, this looks as follows:</p>\n<pre><code class=\"language-java\">// Create a search parameter definition\nSearchParameter eyeColourSp = new SearchParameter();\neyeColourSp.addBase(&quot;Patient&quot;);\neyeColourSp.setCode(&quot;eyecolour&quot;);\neyeColourSp.setType(org.hl7.fhir.dstu3.model.Enumerations.SearchParamType.TOKEN);\neyeColourSp.setTitle(&quot;Eye Colour&quot;);\neyeColourSp.setExpression(&quot;Patient.extension('http://acme.org/eyecolour')&quot;);\neyeColourSp.setXpathUsage(org.hl7.fhir.dstu3.model.SearchParameter.XPathUsageType.NORMAL);\neyeColourSp.setStatus(org.hl7.fhir.dstu3.model.Enumerations.PublicationStatus.ACTIVE);\n// Upload it to the server\nclient\n\t.create()\n\t.resource(eyeColourSp)\n\t.execute();</code></pre>\n<p>The resulting SearchParameter resource looks as follows:</p>\n<pre><code class=\"language-json\">{\n\t&quot;resourceType&quot;: &quot;SearchParameter&quot;,\n\t&quot;title&quot;: &quot;Eye Colour&quot;,\n\t&quot;base&quot;: [ &quot;Patient&quot; ],\n\t&quot;status&quot;: &quot;active&quot;,\n\t&quot;code&quot;: &quot;eyecolour&quot;,\n\t&quot;type&quot;: &quot;token&quot;,\n\t&quot;expression&quot;: &quot;Patient.extension('http://acme.org/eyecolour')&quot;,\n\t&quot;xpathUsage&quot;: &quot;normal&quot;\n}</code></pre>\n<p><strong>2. Upload Some Resources</strong></p>\n<p>Let's upload two Patient resources with different eye colours.</p>\n<pre><code class=\"language-java\">Patient p1 = new Patient();\np1.setActive(true);\np1.addExtension().setUrl(&quot;http://acme.org/eyecolour&quot;).setValue(new CodeType(&quot;blue&quot;));\nclient\n\t.create()\n\t.resource(p1)\n\t.execute();\nPatient p2 = new Patient();\np2.setActive(true);\np2.addExtension().setUrl(&quot;http://acme.org/eyecolour&quot;).setValue(new CodeType(&quot;green&quot;));\nclient\n\t.create()\n\t.resource(p2)\n\t.execute();</code></pre>\n<p>Here's how one of these resources will look when encoded.</p>\n<pre><code class=\"language-json\">{\n &quot;resourceType&quot;: &quot;Patient&quot;,\n &quot;extension&quot;: [\n {\n &quot;url&quot;: &quot;http://acme.org/eyecolour&quot;,\n &quot;valueCode&quot;: &quot;blue&quot;\n }\n ],\n &quot;active&quot;: true\n}</code></pre>\n<p><strong>3. Search!</strong></p>\n<p>Finally, let's try searching:</p>\n<pre><code class=\"language-java\">Bundle bundle = ourClient\n\t.search()\n\t.forResource(Patient.class)\n\t.where(new TokenClientParam(&quot;eyecolour&quot;).exactly().code(&quot;blue&quot;))\n\t.returnBundle(Bundle.class)\n\t.execute();\nSystem.out.println(myFhirCtx.newJsonParser().setPrettyPrint(true).encodeResourceToString(bundle));</code></pre>\n<p>This produces a search result that contains only the matching resource:</p>\n<pre><code class=\"language-json\">{\n &quot;resourceType&quot;: &quot;Bundle&quot;,\n &quot;id&quot;: &quot;bc89e883-b9f7-4745-8c2f-24bf9277664d&quot;,\n &quot;meta&quot;: {\n &quot;lastUpdated&quot;: &quot;2017-02-07T20:30:05.445-05:00&quot;\n },\n &quot;type&quot;: &quot;searchset&quot;,\n &quot;total&quot;: 1,\n &quot;link&quot;: [\n {\n &quot;relation&quot;: &quot;self&quot;,\n &quot;url&quot;: &quot;http://localhost:45481/fhir/context/Patient?eyecolour=blue&quot;\n }\n ],\n &quot;entry&quot;: [\n {\n &quot;fullUrl&quot;: &quot;http://localhost:45481/fhir/context/Patient/2&quot;,\n &quot;resource&quot;: {\n &quot;resourceType&quot;: &quot;Patient&quot;,\n &quot;id&quot;: &quot;2&quot;,\n &quot;meta&quot;: {\n &quot;versionId&quot;: &quot;1&quot;,\n &quot;lastUpdated&quot;: &quot;2017-02-07T20:30:05.317-05:00&quot;\n },\n &quot;text&quot;: {\n &quot;status&quot;: &quot;generated&quot;,\n &quot;div&quot;: &quot;&lt;div xmlns=\\&quot;http://www.w3.org/1999/xhtml\\&quot;&gt;&lt;table class=\\&quot;hapiPropertyTable\\&quot;&gt;&lt;tbody/&gt;&lt;/table&gt;&lt;/div&gt;&quot;\n },\n &quot;extension&quot;: [\n {\n &quot;url&quot;: &quot;http://acme.org/eyecolour&quot;,\n &quot;valueCode&quot;: &quot;blue&quot;\n }\n ],\n &quot;active&quot;: true\n },\n &quot;search&quot;: {\n &quot;mode&quot;: &quot;match&quot;\n }\n }\n ]\n}</code></pre>\n<h2>Custom Search Parameters in Smile CDR</h2>\n<p>Naturally, this feature will soon be available in Smile CDR. Previous versions of Smile CDR had a less elegant solution to this problem; however, now that we have a nice elegant approach to custom parameters that is based on FHIR's own way of handling this, Smile CDR users will see the benefits quickly.</p>\n"
} ]
}
}, {
"fullUrl": "https://smilecdr.com/hapi-fhir/blog/fhir/baseR4/Communication/20170201_gitlab_and_exactly_how_to_handle_an_outage",
"resource": {
"resourceType": "Communication",
"id": "20170201_gitlab_and_exactly_how_to_handle_an_outage",
"meta": {
"versionId": "1",
"tag": [ {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Outages"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "DevOps"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Git"
} ]
},
"language": "en",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>I love <a href=\"https://gitlab.com\" target=\"_blank\">GitLab</a>. Let's get that out of the way.</p>\n<p>Back when I first joined the HAPI project, we were using <a href=\"https://en.wikipedia.org/wiki/Concurrent_Versions_System\" target=\"_blank\">CVS</a> for version control, hosted on SourceForge. Sourceforge was at that point a pretty cool system. You got free project hosting for your open source project, a free website, and shell access to a server so you could run scripts, edit your raw website, and whatever else you needed to do. That last part has always amazed me; I've always wondered what lengths SourceForge must have had to go to in order to keep that system from being abused.</p>\n<p>Naturally, we eventually discovered GitHub and happily moved over there – and HAPI FHIR remains a happy resident of GitHub. We're now in the progress of migrating the HAPI Hl7v2.x codebase over to <a href=\"https://github.com/hapifhir/hapi-hl7v2/\" target=\"_blank\">a new home on GitHub</a>, too.</p>\n<h2>Along comes GitLab</h2>\n<p>The Smile CDR team discovered GitLab about a year ago. We quickly fell in love: easy self-hosting, a UI that feels familiar to a GitHub user yet somehow slightly more powerful in each part you touch, and a compelling set of features in the enterprise edition as well once you are ready for them.</p>\n<p>On Tuesday afternoon, <a href=\"https://smilecdr.com/about_us.htmlFHIR_READ_ALL_OF_TYPE#diederik\">Diederik</a> noticed that GitLab was behaving slowly. I was curious about it since GitLab's <a href=\"https://twitter.com/gitlabstatus\" target=\"_blank\">@gitlabstatus</a> Twitter mentioned unknown issues affecting the site. As it turned out, their issues went from bad, to better, and then to much worse. Ultimately, they wound up being unavailable for all of last night and part of this morning.</p>\n<h2>A terrible day for them!</h2>\n<p>GitLab's issues were slightly hilarious but also totally relatable to anyone building and deploying big systems for any length of time. TechCrunch has a nice <a href=\"https://techcrunch.com/2017/02/01/gitlab-suffers-major-backup-failure-after-data-deletion-incident/\" target=\"_blank\">writeup of the incident</a> if you want the gory details. Let's just say they had slowness problems caused by a user abusing the system, and in trying to recover from that a sysadmin accidentally deleted a large amount of production data. Ultimately, he thought he was in a shell on one (bad) node and just removing a useless empty directory but he was actually in a shell on the (good) master node.</p>\n<p>I read a few meltdowns about this on reddit today, calling the sysadmin inexperienced, inept, or worse, but I also saw a few people saying something that resonated with me much more: if you've never made a mistake on a big complicated production system, you've probably never worked on a big complicated production system.</p>\n<p>These things happen. The trick is being able to recover from whatever has gone wrong, no matter how bad things have gotten.</p>\n<h2>An exercise in good incident management</h2>\n<img src=\"20170201_gitlab_and_exactly_how_to_handle_an_outage/gitlabfail02.gif\" style=\"max-width: 500px;\" class=\"PostCaptionTopRight\"/>\n<p>This is where GitLab really won me over. Check their <a href=\"https://twitter.com/gitlabstatus\" target=\"_blank\">Twitter</a> for yourself. There was no attempt to mince words. GitLab engineers were candid about what had happened from the second things went south.</p>\n<p>GitLab opened a publicly readable Google Doc where all of the notes of their investigation could be read by anyone wanting to follow along. When it became clear that the recovery effort was going to be long and complicated, they opened a YouTube live stream of a conference bridge with their engineers chipping away at the recovery.</p>\n<p>They even opened a live chat with the stream so you could comment on their efforts. Watching it was great. I've been in their position many times in my life: tired from being up all night trying to fix something, and sitting on an endless bridge where I'm fixing one piece, waiting for others to fix theirs, and trying to keep morale up as best I can. GitLab's engineers did this, and they did it with cameras running.</p>\n<p>So this is the thing: I bet GitLab will be doing a lot of soul-searching in the next few days, and hopefully their tired engineers will get some rest soon. In the end, the inconvenience of this outage will be forgotten but I'm sure this won't be the last time I'll point to the way they handled a critical incident with complete transparency, and set my mind at ease that things were under control.</p>\n</div>"
},
"status": "completed",
"sent": "2017-02-01T20:37:00-05:00",
"sender": {
"reference": "https://smilecdr.com/about_us/#james",
"display": "James Agnew"
},
"payload": [ {
"contentString": "<p>I love <a href=\"https://gitlab.com\" target=\"_blank\">GitLab</a>. Let's get that out of the way.</p>\n<p>Back when I first joined the HAPI project, we were using <a href=\"https://en.wikipedia.org/wiki/Concurrent_Versions_System\" target=\"_blank\">CVS</a> for version control, hosted on SourceForge. Sourceforge was at that point a pretty cool system. You got free project hosting for your open source project, a free website, and shell access to a server so you could run scripts, edit your raw website, and whatever else you needed to do. That last part has always amazed me; I've always wondered what lengths SourceForge must have had to go to in order to keep that system from being abused.</p>\n<p>Naturally, we eventually discovered GitHub and happily moved over there – and HAPI FHIR remains a happy resident of GitHub. We're now in the progress of migrating the HAPI Hl7v2.x codebase over to <a href=\"https://github.com/hapifhir/hapi-hl7v2/\" target=\"_blank\">a new home on GitHub</a>, too.</p>\n<h2>Along comes GitLab</h2>\n<p>The Smile CDR team discovered GitLab about a year ago. We quickly fell in love: easy self-hosting, a UI that feels familiar to a GitHub user yet somehow slightly more powerful in each part you touch, and a compelling set of features in the enterprise edition as well once you are ready for them.</p>\n<p>On Tuesday afternoon, <a href=\"https://smilecdr.com/about_us.htmlFHIR_READ_ALL_OF_TYPE#diederik\">Diederik</a> noticed that GitLab was behaving slowly. I was curious about it since GitLab's <a href=\"https://twitter.com/gitlabstatus\" target=\"_blank\">@gitlabstatus</a> Twitter mentioned unknown issues affecting the site. As it turned out, their issues went from bad, to better, and then to much worse. Ultimately, they wound up being unavailable for all of last night and part of this morning.</p>\n<h2>A terrible day for them!</h2>\n<p>GitLab's issues were slightly hilarious but also totally relatable to anyone building and deploying big systems for any length of time. TechCrunch has a nice <a href=\"https://techcrunch.com/2017/02/01/gitlab-suffers-major-backup-failure-after-data-deletion-incident/\" target=\"_blank\">writeup of the incident</a> if you want the gory details. Let's just say they had slowness problems caused by a user abusing the system, and in trying to recover from that a sysadmin accidentally deleted a large amount of production data. Ultimately, he thought he was in a shell on one (bad) node and just removing a useless empty directory but he was actually in a shell on the (good) master node.</p>\n<p>I read a few meltdowns about this on reddit today, calling the sysadmin inexperienced, inept, or worse, but I also saw a few people saying something that resonated with me much more: if you've never made a mistake on a big complicated production system, you've probably never worked on a big complicated production system.</p>\n<p>These things happen. The trick is being able to recover from whatever has gone wrong, no matter how bad things have gotten.</p>\n<h2>An exercise in good incident management</h2>\n<img src=\"20170201_gitlab_and_exactly_how_to_handle_an_outage/gitlabfail02.gif\" class=\"PostCaptionTopRight\" style=\"max-width: 500px;\"/>\n<p>This is where GitLab really won me over. Check their <a href=\"https://twitter.com/gitlabstatus\" target=\"_blank\">Twitter</a> for yourself. There was no attempt to mince words. GitLab engineers were candid about what had happened from the second things went south.</p>\n<p>GitLab opened a publicly readable Google Doc where all of the notes of their investigation could be read by anyone wanting to follow along. When it became clear that the recovery effort was going to be long and complicated, they opened a YouTube live stream of a conference bridge with their engineers chipping away at the recovery.</p>\n<p>They even opened a live chat with the stream so you could comment on their efforts. Watching it was great. I've been in their position many times in my life: tired from being up all night trying to fix something, and sitting on an endless bridge where I'm fixing one piece, waiting for others to fix theirs, and trying to keep morale up as best I can. GitLab's engineers did this, and they did it with cameras running.</p>\n<p>So this is the thing: I bet GitLab will be doing a lot of soul-searching in the next few days, and hopefully their tired engineers will get some rest soon. In the end, the inconvenience of this outage will be forgotten but I'm sure this won't be the last time I'll point to the way they handled a critical incident with complete transparency, and set my mind at ease that things were under control.</p>\n"
} ]
}
}, {
"fullUrl": "https://smilecdr.com/hapi-fhir/blog/fhir/baseR4/Communication/20170117_hl7_wgm_san_antonio",
"resource": {
"resourceType": "Communication",
"id": "20170117_hl7_wgm_san_antonio",
"meta": {
"versionId": "1",
"tag": [ {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "HL7"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Meetings"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "Connectathon"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "FHIR"
}, {
"system": "https://smilecdr.com/hapi-fhir/blog/tag",
"code": "WGM"
} ]
},
"language": "en",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><img src=\"20170117_hl7_wgm_san_antonio/IMG_20170116_214308.jpg\" class=\"blog-post-image-fullwidth\"/>\n<p>It's January again, which of course means it's time for the January HL7 Working Group Meeting. As always, the first two days of the HL7 meeting brings FHIR Connectathon, and this was Connectathon 14.</p>\n<p>I feel like every time I visit one of these meetings, the scale of the meeting astounds me and I can't imagine it being any bigger... and then that happens again the next time. The final tally at the September 2016 (Baltimore) Connectathon was 170 people. The final tally here in San Antonio was 209 so we continue to beat expectations.</p>\n<p>I think we are finally passing a point where it's feasible to fit everyone in a half-size hotel ballroom. We may well have some hard decisions about whether the format still works or whether we need to turn people away in September.</p>\n<p>Also amazing to me was the number of new faces. On the first day, <a href=\"https://github.com/ewoutkramer\" target=\"_blank\">Ewout Kramer</a> asked the room for anyone who was a first-time attendee to a FHIR Connectathon to raise their hand. It looked like about half the room raised their hand so we're really expanding the pool of interested people right now. Exciting days for FHIR!</p>\n<p>Monday night brought our usual HAPI &amp; .NET Users Group. We discussed a proposal we're working on for a template-based approach to automatic resource narrative generation. There will be more on that in a future post.</p>\n</div>"
},
"status": "completed",
"sent": "2017-01-17T18:00:00-05:00",
"sender": {
"reference": "https://smilecdr.com/about_us/#james",
"display": "James Agnew"
},
"payload": [ {
"contentString": "<img src=\"20170117_hl7_wgm_san_antonio/IMG_20170116_214308.jpg\" class=\"blog-post-image-fullwidth\"/>\n<p>It's January again, which of course means it's time for the January HL7 Working Group Meeting. As always, the first two days of the HL7 meeting brings FHIR Connectathon, and this was Connectathon 14.</p>\n<p>I feel like every time I visit one of these meetings, the scale of the meeting astounds me and I can't imagine it being any bigger... and then that happens again the next time. The final tally at the September 2016 (Baltimore) Connectathon was 170 people. The final tally here in San Antonio was 209 so we continue to beat expectations.</p>\n<p>I think we are finally passing a point where it's feasible to fit everyone in a half-size hotel ballroom. We may well have some hard decisions about whether the format still works or whether we need to turn people away in September.</p>\n<p>Also amazing to me was the number of new faces. On the first day, <a href=\"https://github.com/ewoutkramer\" target=\"_blank\">Ewout Kramer</a> asked the room for anyone who was a first-time attendee to a FHIR Connectathon to raise their hand. It looked like about half the room raised their hand so we're really expanding the pool of interested people right now. Exciting days for FHIR!</p>\n<p>Monday night brought our usual HAPI &amp; .NET Users Group. We discussed a proposal we're working on for a template-based approach to automatic resource narrative generation. There will be more on that in a future post.</p>\n"
} ]
}
} ]
}
Wrote 49.2 KB (117.7 KB total including HTML) in estimated 8ms