Converting v2 to FHIR

May 9, 2019 4 Comments

At the recent Working Group Meeting in Montreal, I participated in the ‘v2 to FHIR’ stream – focused on how can the HL7 community give advice to implementers about converting v2 messages into FHIR bundles.

Broadly there are 2 approaches to this conversion:

  • The creation of a FHIR message bundle that mirrors the contents of the v2 message, and is intended to be an equivalent representation, behaving in the same way as v2 messages
  • Using the contents of the v2 message to update a FHIR server – perhaps extracting Encounter resources or creating a Bundle that is intended to act as a ‘transaction’ bundle against a FHIR server. I think this will be a much more common use case.

In either case, it’s desirable that HL7 should provide the mappings (insofar as that is possible in v2) from v2 to FHIR.

Read more of this post

Filed under Uncategorized

Importing CSV data into a FHIR server

March 25, 2019 Leave a comment

Suppose you have a csv file of data, and you want to load that into a FHIR server. There are a number of ways that you could do that – depending on the nature of the csv file and the capabilities of the FHIR server that you want to update.

Let’s work through a simple scenario.

Read more of this post

Filed under node-RED

Securing a FHIR endpoint in Node-RED

March 15, 2019 2 Comments

So in a comment to the previous post on using Node-RED to create Tasks from Assessments, Michael suggested that I talk about some of the  security considerations that you might have. There are a few ways you could make this more secure that I can think of.

  • The simplest way would be to put the whole thing behind as API manager (such as APIgee or WSO2) and delegate security to that application. In effect you are trusting the API manager.
  • Another way is to follow the SMART / OAuth process – check that a valid access token issued by an Authorization Server (Authz) has been provided in the call, rejecting the call if not.
  • And yet another option is to perform the whole OAuth2 dance – look for a valid access token, taking on the role of the Authorization server if not – validating the user and issuing tokens.

(And there will be plenty of others I’m sure). Naturally all calls will use SSL.

Let’s look a bit further into the second option – checking for a valid access token, and simply rejecting the call if there is not one present.

Read more of this post

Filed under node-RED, SMART

Using Node-RED to implement clinical workflow

March 14, 2019 3 Comments

So a colleague came to me with an interesting challenge – how can you use Node-RED to implement clinical workflow? That’s a rather broad topic, so let’s take a simple use case.

Suppose you have an assessment, and as part of that assessment you want to be able to create a number of actions. For example you might want to book an appointment, order a test, notify someone if a score is above a threshold or enrol them on a case management programme. Let’s look at how we might implement this in Node-RED and FHIR.

Read more of this post

Filed under Clinical, node-RED

How to Profile

March 7, 2019 Leave a comment

Just came across this resource from the firely folk. Michel (author of Forge) pointed me to it when i was asking slicing questions on the FHIR chat.

A great introduction to profiling in FHIR using the Forge tool for concrete examples and well worth a look …

Filed under Uncategorized

Provider Directories – part 2

January 15, 2019 Leave a comment

In the previous post, we set up the environment for our provider registry and imported some test data (Practitioner only at this stage) from an existing reference server. Now let’s think about how we can go about exposing that information through an API. We’ll work with 2 use cases – which can then act as a pattern for future APIs.

Read more of this post

Filed under directory Tagged with

Provider Directories – part 1

January 14, 2019 1 Comment

So I’ve been sort of following the Validated Directory track at the Connectathon in San Antonio. I say ‘sort of’ because I’m interested in the idea of using the VerificationResult resource to track the provenance of individual entries in a registry (though I’m not entirely clear about the relationship between VerificationResult and Provenance).

Update: After a chat with those who know these things, the Provenance resource indicates who actually created the resource, while the VerificationResult is who said the information was correct. So I might create a Practitioner resource with my qualifications (so the Provenance points to me) while my Medical School confirms that I do, indeed, have a medical degree – which would be the VerificationResult. And there could be multiple VerificationResults if, say, the check needed to be repeated.

Read more of this post

Filed under connectathon, directory

← Older posts

Newer posts →