Request for Comments and Change process for ODA Application Interfaces

We are conforming with a classic RFC process to continuously maintain a dialogue with stakeholders and the developer community. https://en.wikipedia.org/wiki/Request_for_Comments

Please see https://github.com/omahoito/rfc/projects/1 for the progress of requests.

Current schemas are in https://simplifier.net/FinnishPHR

• Profiles define the structures of the resources, data types, extensions and constraints used in ODA FHIR API. Profile implementers are expected to be familiar with the HL7 guidelines: http://hl7.org/fhir/profiling.html
• Profile names start with project identifier "ODA" and the profile name must contain the resource and the special domain of the particular resource (if any). For example a care plan for customer's self care is named as "ODA self-CarePlan profile".
• Profiles must be in XML format and their filenames must contain the profile name, for example ODA-self-CarePlan.profile.xml
• Profile name should be in PascalCase, not camelCase, i.e. "ODA CarePlan" as well as filenames ie. ODA-CarePlan.profile.xml
• For each profile there must be also an example resource in JSON format. Example resource demonstrates how the data elements are used and its name must match to the profile name, for example: ODA-self-careplan.example.json.
• Profiles must be compatible with HL7 FHIR STU3 standard.
• A constraining profile can only allow what the base profile allows. Limitations are described more detailed in HL7 FHIR standard: http://hl7.org/fhir/profiling.html#5.1.0.7
• Each profile must contain both the snapshot and differential components. The snapshot component shows all resource elements in one description and the differential component describes the differencies compared to the base profile.
• Documenting the profile elements: Profile element definitions (http://hl7.org/fhir/elementdefinition.html) contain elements describing what the element is, why it exists and how it should or could be used. These include:
  • definition: A narrative text containing full formal definition of the element. This is required for all modified extensions or profile elements.
  • comments: Comments and other relevant information about the use of this element. This is optional.
  • requirements: Description why this element exists. This is optional.
  • example: Example value for the element. This is optional.
  • For example, the "category" element of the self-careplan profile could have following element definitions:
    • definition: "Identifies what kind of plan this is to support differentiation between multiple co-existing plans; e.g. "Self-care", "Diabetes" etc."
    • comments: "Only allowed value is 'Self-care'"
    • requirements: "This allows filtering different kinds of care-plans"

Data models of the following profiles:

• ActivityDefinition

  • Profile documentation STU3
  • Profile as xml
  • Example resource as json

• Appointment

  • Profile as xml
  • Example resource as json
  • Profile documentation (STU3)
  • Discussion

• CarePlan

  • Profile as xml
  • Example resource as json
  • Profile documentation STU3
  • Discussion

• CareTeam

  • Profile as xml
  • Example resource as json
  • Profile documentation STU3
  • Introduced in STU3
  • Discussion

• Communication, used in communication between patient and practitioner

  • Profile as xml
  • Example resource as json
  • Profile documentation STU3)
  • Discussion

• EpisodeOfCare, contains information about the association of a patient with a healthcare provider (e.g. practitioner)

  • Profile as xml
  • Example resource as json
  • Documentation: STU3

• Goal, setting a goal for the patient's recovery

  • Profile as xml
  • Example resource as json
  • Documentation: STU3

• MedicationStatement, information about medication the patient is using

  • Profile as xml
  • Example resource as json
  • Documentation STU3

• Observation about body temperature, contains patient's temperature measurements

  • Profile as xml
  • Example resource as json
  • Profile documentation (STU3)

• Organization, an entity managing health resources

  • Profile as xml
  • Example resource as json
  • Documentation (STU3)

• Person - FinnishPatient. Person and patient information. Person-profile is based on the FHIR-standard's STU3-version, FinnishPatient on Kela's profile

  • Person: http://hl7.org/fhir/person.html
  • Kela's FinnishPatient-profile: https://simplifier.net/FinnishPHR/FinnishPatient/
  • Resources as json:
    • Person
    • Patient
  • Discussion

• Practitioner, professional who takes care of patient

  • Profile as xml
  • Example resource as json
  • Documentation STU3

• Questionnaire

  • Profile as xml
  • Example resource as json
  • Documentation STU3

• QuestionnaireResponse

  • Profile as xml
  • Example resource as json
  • Documentation STU3

• CarePlan is the central element in ODA data model as it gathers the care related information for the patient. The CarePlan contains actions suggested by symptom check service. Patient may also attach his/her personal health or activity data from Kela PHR and healthcare data from Kela Kanta to CarePlan. This supporting information is referenced by CarePlan.support element
• ActivityDefinition Definition of the suggested action. These definitions are referenced by careplan activities.
• CareTeam models two objects:
  • The service request list containing professionals authorized to the list.
  • The care team participating to patient's ODA-care
• Practitioner models the professional and contains the professional data shown in ODA.
• Patient Patient models a patient without any personal information. Conforms to Finnish PHR FinnishPatient profile
• Person Person contains personal information of a user.
• Observation references to Patient. When generated from the questionnaire answer, references also to corresponding QuestionnaireResponse resource. For vital signs conforms to Finnish PHR Vital Signs profile and the profiles derived from it.
• EpisodeOfCare is created when care-relationship starts between professional and patient. CareManager relates to the responsible professional and the team contains other professionals participating to care.
• Questionnaire Created by main user and saved to PHR as questionnaire templates.
• QuestionnaireResponse Created when patient answers to a questionnaire and saves the answers.
• Communication Patient's and professional's comments about the CarePlan or any other resource.
• MedicationStatement Medication information added by patient. Authorized to care-team by linking CarePlan to the MedicationStatement instance.
• Immunization Added by patient and authorized to care-team via careplan.
• AllergyIntolerance Added by patient and authorized to care-team via careplan.
• Flag Risk-information added by patient and authorized to care-team via careplan.
• Organization Managing organization of the CareTeam representing the service request list.
• Goal The "master" goal of the patient.

Notepad++ has a plugin for FHIR. http://www.healthintersections.com.au/?p=2386

Install files here: http://www.healthintersections.com.au/FhirServer/fhirnpp.htm

Forge is a FHIR profile editor for Windows. http://fhir.furore.com/forge https://simplifier.net/ui/Info/Forge

Connects to Simplifier, a registry for FHIR profiles.

Simple FHIR editor online at http://docs.smarthealthit.org/fred/ source: https://github.com/smart-on-fhir/fred

FHIR Resource Editor (FRED) usage is simple and intuitive. The choice of elements is limited. No custom elements. If attempt with custom elements, they will be displayed as red. Null and undefined values give message about profile containing errors.

A separate instance of FRED can be set up and run on a server.

There are currently no known FHIR editing tools for Linux or Mac.

The profile data schemas are written in XML. Forge is a tool with to create and comment FHIR profiles. It also shows the structure of the data schema.

Forge makes it possible to focus on the functional side of modelling without having to get involved in the complexity of XML files. Forge also automatically validates the profiles.

Forge can be downloaded here. The software only works in Windows. It is only possible to do profiles in XML format.

In Forge the profile elements and attributes can be commented in the "Comments" or "Reason for inclusion and constrainment" sections. The comments section can include explanatory comments and application information, and information on the correct way of using the element. The reason section can include information about why an element or attribute has been created, and also include references to support these decisions.

If you are interested in contributing new profiles, please feel free to do so. The profiles have been made with Forge, and the same tool can be used for further development or modification of existing profiles or creation of new ones. Please see the Profiling section for further information.

Contributions are done through pull requests. Profile files are checked with xmllint and Travis. Please add a validation test for the profile to the validation script together with the schema file that the profile is based on. Passing the validation test is a precondition for new profiles to be accepted.

Schema validation files for DSTU2 profiles are located here and files for STU3 can be found here. The schema files end with a xsd suffix.

Since May 2017, only STU3 based profiles are used in the profiling.

Example resources have been written by hand. Like the profiles, the resources are also automatically validated. The validation is done with JSON Spec and the validation routine automatically run on Travis. If you want to contribute an example, please do so through a pull request.